View
0
Download
0
Category
Preview:
Citation preview
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE
ACADEMIEJAAR 2015– 2016
Een vergelijkende studie tussen het klassieke project management en de
concepten Agile/Lean
Masterproef voorgedragen tot het bekomen van de graad van
Master of Science in de
Toegepaste Economische Wetenschappen: Handelsingenieur
Matthias Cauchie en Ide De Clercq
onder leiding van
Prof. Dr. Mario Vanhoucke
Annelies Martens
PERMISSION
Ondergetekenden verklaren dat de inhoud van deze masterproef mag geraadpleegd en/of gereprodu-
ceerd worden, mits bronvermelding.
Matthias Cauchie en Ide De Clercq
Woord vooraf
Deze thesis is het sluitstuk van onze opleiding Handelsingenieur afstudeerrichting Operationeel Mana-
gement aan Universiteit Gent. Het schrijven van deze masterproef was niet mogelijk geweest zonder
de hulp van een aantal mensen.
Eerst en vooral willen we Professor Mario Vanhoucke bedanken om ons de opportuniteit te bieden om
dit interessante onderwerp te onderzoeken. Daarnaast ook een woord van dank voor onze begeleid-
ster Annelies Martens, voor haar wijze raad, opvolging en begeleiding doorheen het volledige project.
Verder bedanken we ook de volgende projectmanagers:
Erik Martens - Senior Project Manager bij ING
Tim Vanspeybroeck - Project Manager bij Threon
Pepijn Verhaeghe - Lean Coach bij Volvo Trucks
Christophe Wauthier - Project Manager bij Volvo Trucks
Dieter Verlaeckt - IT-director bij Bru Textiles
Wendy Verborgh - Project Manager bij Toyota Material Handling Duitsland
Koenraad Vastmans - Agile Coach bij KBC
Harrie Vanden Elzen - Project Manager bij DHL
Niels Helderman - Team Lead Project Management bij DHL
Hun bijdrage was een grote meerwaarde voor onze casestudies. Ze namen steeds uitgebreid de tijd om
met ons een bepaald project te doorlopen. Dankzij hun expertise kregen we nieuwe inzichten en een
beter beeld over de manier waarop verschillende bedrijven omgaan met projectmanagement.
Bijzondere dank gaat uit naar Chris Kindermans voor zijn leerrijke inzichten en het delen van zijn
opinies en gedachten. Zijn feedback en raad hebben ons geholpen inhoudelijke en structurele verbete-
ringen aan te brengen.
Tenslotte zouden we ook onze ouders en vrienden willen bedanken voor hun onvoorwaardelijke steun
en blijvende aanmoedigingen.
Inhoudsopgave
1 Inleiding 1
1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Toegevoegde waarde aan eerder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Literatuurstudie 3
2.1 Klassiek PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Principes van Klassiek PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Frameworks voor Klassiek PM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3 Moeilijkheden met Klassiek PM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Lean PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Principes van Lean PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Frameworks voor Lean PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Moeilijkheden met Lean PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Principes van Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2 Frameworks voor Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3 Moeilijkheden met Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.4 Interpretaties rond Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 Klassiek PM vs Lean PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5 Klassieke PM vs Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6 Lean PM vs Agile PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3 Bevindingen uit de praktijk 51
3.1 IT-Projecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.1 The Standish Group: Chaos Report . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.2 Bru Textiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.2.1 Projectbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.2.2 Voordelen van Agile PM voor Bru Textiles . . . . . . . . . . . . . . . 57
3.1.2.3 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.1.3 IT project binnen Volvo Trucks . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.3.1 Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.3.2 Projectbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1.3.3 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 Constructieprojecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2.1 Aanpak en mogelijkheden voor andere methodes . . . . . . . . . . . . . . . . . 67
3.2.1.1 Klassieke aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2.1.2 Lean aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.2.1.3 Agile aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.2.2 Constructieproject Antwerpen . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.2.1 Projectbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.2.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3 Overheidsprojecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.1 Constructie project Station Gent Sint Pieters . . . . . . . . . . . . . . . . . . . 72
3.3.1.1 Projectbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.1.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4 Projecten in de banksector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4.1 Projectaanpak bij ING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4.2 PARIS-Project binnen KBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.4.2.1 Projectbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.4.2.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5 Projecten in de Logistieke sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5.1 DHL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5.1.1 Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5.1.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.6 Projecten in de auto-industrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.6.1 Toyota Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.6.1.1 Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.6.1.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4 Algemeen besluit 95
5 Bibliografie 97
6 Bijlagen I
Lijst van figuren
1 Project Triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Project Life Cycle van PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 PERT-techniek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Example of the Critical Chain Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Work Breakdown Structure (Vanhoucke, 2013) . . . . . . . . . . . . . . . . . . . . . . 13
6 Distribution of frameworks used in projectmanagement (PWC, 2007) . . . . . . . . . . 16
7 Verdeling van slagen van IT projecten in de VS in 2006 (The Standish Group) . . . . 18
8 House of Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9 Onderzoek van ‘The Standish Group’ naar het gebruik van functies in de custom soft-
ware applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10 Het Lean Project Delivery System (LPDS) . . . . . . . . . . . . . . . . . . . . . . . . 26
11 Effect van teamgrootte op het succesratio van het project . . . . . . . . . . . . . . . . 30
12 State of Agile Survey 2015: Verdeling van methodologieen in de software-ontwikkeling 36
13 Competing Values Model (Quinn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
14 Verschil tussen het Traditioneel PM en Agile PM mbt Scope Triangle . . . . . . . . . 47
15 Chaos Report 2015: Evolutie van distributie ivm het slagen van projecten . . . . . . . 51
16 Vergelijking van projectresultaten tussen Waterfall en Agile . . . . . . . . . . . . . . . 52
17 Projectplanning: Geautomatiseerd magazijn Bru Textiles . . . . . . . . . . . . . . . . 55
18 Geautomatiseerd magazijn: Burn-up chart . . . . . . . . . . . . . . . . . . . . . . . . . 57
19 Information System Global Development Process . . . . . . . . . . . . . . . . . . . . . 59
20 Key areas in het IS-GDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
21 Verloop van ‘Subproject 1’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
22 Verloop van ‘Subproject 3’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
23 Planning na de workshop in week 46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
24 Vertraging in ‘Subproject 1’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
25 Conflict van ‘Subproject 1’ met ‘Subproject 3’ . . . . . . . . . . . . . . . . . . . . . . . 64
26 Oplossing voor het conflict van ‘Subproject 1’ met ‘Subproject 3’ . . . . . . . . . . . . 64
27 Vertraging in het EOP tijdsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
28 Kostenoverzicht van het project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
29 Verloop van project in traditioneel projectmanagement . . . . . . . . . . . . . . . . . . 69
30 Designfase van het constructieproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
31 Ontwikkelingsfase van het constructieproject . . . . . . . . . . . . . . . . . . . . . . . 71
32 Overzicht van de verschillende fasen in het GSP-project . . . . . . . . . . . . . . . . . 73
33 Overzicht van de verschillende mijlpalen in het GSP-project . . . . . . . . . . . . . . . 74
34 Detailplan met de activiteiten voor de bouw van perron 11 . . . . . . . . . . . . . . . 75
35 Scaled Agile Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
36 Burn-Up chart van het PARIS project . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
37 Burn-Up chart van het PARIS project per gebied . . . . . . . . . . . . . . . . . . . . . 82
38 Capaciteitsplanning PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
39 Sprint Story Burn-down chart PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
40 Sprint Item Burn-up chart PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
41 Controle van de snelheid per sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
42 Controle van het budget PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
43 Business capacity PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
44 DHL Project Workbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
45 Oobeya room Toyota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
46 Barashi Board Toyota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
47 Barashi Board Tools Toyota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
48 Overzicht van de DePict Project Management aanpak . . . . . . . . . . . . . . . . . . III
1 Inleiding
1.1 Motivatie
De eerste en veruit belangrijkste opgave bij het schrijven van een thesis is het kiezen van een geschikt
onderwerp. Het onderwerp moet aanspreken, het moet gaan over iets waarvoor de bereidheid om eraan
te werken groot is. Extreem gesteld: als de thesis eerder als vrijetijdsbesteding wordt beschouwd dan
als opdracht, is reeds de helft van het benodigde werk geleverd.
In het verleden hebben we samen al verschillende academische opdrachten tot een goed einde gebracht,
waardoor het voor ons evident was om samen deze thesis aan te vatten. De mogelijkheid om elkaar
kritisch te beoordelen, zagen wij als een grote meerwaarde.
Aangezien onze interesse meteen werd opgewekt tijdens het vak Project Management van Professor
Vanhoucke, was de keuze voor ons snel gemaakt om onze thesis binnen dit vakgebied te schrijven.
Met de concepten Lean en Agile zijn we gedurende het vak Productiebeleid van Professor Chalmet in
aanraking gekomen. Lean hebben we daar vooral bestudeerd in een productie-omgeving. Het leek ons
echter interessant om dit onderwerp te bestuderen in een projectmanagement omgeving.
Een studie van het Project Management Institute in December 2015 toont aan dat projectmanagement
alomtegenwoordig is in de hedendaagse industrie. Wanneer een organisatie gebruik maakt van een
formele projectmanagement methodiek, ervaren ze dat 80% van hun projecten tegemoetkomt aan de
vooropgestelde doelen. Bedrijven die geen gebruik maken van een vaste projectmethodiek, leveren
slechts in 54% van de gevallen een gunstig project op. Dit toont aan dat het voor bedrijven belangrijk
is om op een gestructureerde manier om te gaan met hun projecten.
1.2 Probleemstelling
De concepten Lean en Agile zijn vandaag de dag niet meer uit de bedrijfswereld weg te denken. In
projectmanagement winnen ze alsmaar meer aan belang. Deze vernieuwende ideeen staan in schril
contrast met de traditionele aanpak. Een groot deel van de klassieke denkers staat kritisch tegenover
deze nieuwe ontwikkelingen. Toch kan men stellen dat de wereld vandaag de dag gekenmerkt wordt
door een steeds veranderende omgeving. Ook in de bedrijfsomgeving is dit eerder de regel dan de
uitzondering. De opzet in deze thesis is om een kwalitatief onderzoek te voeren naar de huidige
toestand van het projectmanagement binnen verschillende sectoren in Vlaanderen.
1
1.3 Aanpak
Het is de bedoeling van dit werk om aan de hand van casestudies informatie bij bedrijven in Vlaande-
ren te verzamelen omtrent hun methodiek voor projectmanagement. Aan de hand van getuigenissen
kunnen we te weten komen welke voordelen en moeilijkheden zij ervaren bij het gebruik van hun spe-
cifieke projectaanpak. Van een student wordt verwacht dat hij kritisch kan omgaan met de informatie
waarmee hij in contact komt. In deze thesis hebben we getracht om deze kritische blik goed naar
voor te brengen. Vooral bij het vergelijken van verschillende methodieken en bij de bespreking van de
casestudies is dit duidelijk zichtbaar.
1.4 Toegevoegde waarde aan eerder onderzoek
Als aanzet voor deze thesis werd de paper ‘Introducing AgiLean to Construction Project Management’
(Demir, Bryde & Sertyesilisik, 2014) beschouwd waarin Lean en Agile worden gevat in een methodiek,
AgiLean. In de literatuurstudie gaan we ook de verschillende methoden onderling vergelijken en zal
besproken worden of deze combinatie behoort tot de toekomstmogelijkheden.
Verder kunnen wij een toegevoegde waarde bieden door een beeld te scheppen van de huidige toe-
stand binnen enkele grote organisaties gevestigd in Vlaanderen op vlak van projectmanagement. Ook
heeft deze thesis als doel om een duidelijker beeld te geven over de meest frequente methoden voor
projectmanagement binnen verschillende sectoren. De thesis kan ook het beginstadium vormen in het
ontwikkelen van een nieuwe techniek die verschillende huidige methodieken probeert te combineren.
1.5 Overzicht
De structuur van deze thesis kan opgedeeld worden in drie grote onderdelen. Eerst is er de literatuur-
studie waar we voor elk van de drie methodes de principes, frameworks en moeilijkheden beschrijven.
Ook vergelijken we de verschillende methodieken onderling en kijken we hoe deze elkaar zouden kunnen
versterken in een gecombineerde aanpak.
In het volgende onderdeel beschrijven we casestudies in verschillende sectoren met de bedoeling om te
evalueren wat de huidige situatie is in elk van deze en met een kritische bril te kijken naar wat beter
kan. We maken hier gebruik van data en getuigenissen van personen die in elk van deze bedrijven
betrokken zijn in het projectmanagement.
Het laatste onderdeel is de conclusie waarin we per sector kort schetsen wat gaande is en wat onze
ideeen zijn over de toekomstperspectieven met betrekking tot projectmanagement in deze sectoren.
2
2 Literatuurstudie
In deze literatuurstudie gaan we elk van de concepten achtereenvolgens beschrijven en vervolgens een
aan een vergelijken. Occasioneel zal ook worden verwezen naar de mening van experten op vlak van
projectmanagement in Belgie met betrekking tot een bepaald statement dat wij aan hen voorlegden.
Eerst zal het klassiek PM aan bod komen.
2.1 Klassiek PM
Het traditionele projectmanagement is gericht op het zeer gedisciplineerd plannen en controleren van
projecten. Het gaat hoofdzakelijk over projecten waarvan de taken na elkaar worden uitgevoerd. Wan-
neer een fase voltooid is, zal worden verdergegaan met de volgende en kan hier enkel op teruggekomen
worden wanneer een duidelijk Change Control mechanisme voorhanden is. Voor de beschrijving van
deze aanpak maken we in de volgende sectie gebruik van de PMBOK, de Project Management Body
of Knowledge.1 Dit is de standaard die ontworpen werd door PMI om als leidraad te gebruiken tijdens
het plannen en uitvoeren van projecten. De vereisten van de klant worden in het begin vastgelegd,
waarna op basis daarvan een schatting gemaakt wordt van de benodigde middelen. Verder wordt de
initiele planning opgemaakt en het budget toegekend. De tijd, scope en het budget liggen van in het
begin vast. Deze elementen kunnen echter op een gecontroleerde manier veranderen gedurende het
project waarbij we rekening moeten houden met de invloed van het ene element op het andere. Deze
dynamiek wordt verduidelijkt in de Project Triangle of Iron Triangle.
Figuur 1: Project Triangle
1The Project Management Body of Knowledge, gepubliceerd door the Project Management Institute (PMI) -
www.pmi.org.
3
Chatfield en Johnson(2003) beschrijven de dynamiek in deze figuur als volgt. De driehoek bestaat
uit drie constraints: scope, tijd en budget. Wanneer je een van de constraints wilt veranderen, zal je
moeten onderzoeken welke impact deze actie zal hebben op de andere constraints. Wanneer meer in
detail gekeken wordt, kan kwaliteit zich onderscheiden van scope en vormt dit een vierde constraint.
Stel nu het scenario waar het project moet voltooid worden in minder tijd. Zoals eerder gesteld leidt
deze aanpassing ook tot het aanpassen van de scope en/of het budget. Ofwel neem je meer mensen in
dienst en stijgen de kosten ofwel kies je ervoor om de scope te laten inkrimpen. In het laatste geval
is het belangrijk dat de kwaliteit wordt gecontroleerd. De kwaliteit mag niet ten koste gaan van een
nakende deadline.
Een tweede scenario is wanneer er minder budget voorhanden is. Dit impliceert dat het project
langer zal duren aangezien je over minder personeel beschikt of het product zal moeten inboeten in
functionaliteiten. Zaken die niet echt noodzakelijk zijn, zullen dan worden weggelaten. Dit zal dan
ook ten koste gaan van de kwaliteit van het product.
Een laatste scenario is wanneer de scope toeneemt. Dit scenario wordt door Wysocki (2003) scope
creep genoemd. Dit is elke aanpassing in de scope die ongecontroleerd gebeurt. Dit kan zich voordoen
wanneer de scope niet voldoende gedefinieerd of gedocumenteerd is. Enkele andere elementen kunnen
aan de oorzaak hiervan liggen. Zo kan het veroorzaakt worden door zwakke controleprocessen, een
zwakke project manager of sponsor, door slechte communicatie tussen de verschillende partijen of een
tekort aan veelzijdigheid van het product. Dit laatste aspect wijst op het feit dat producten vandaag
de dag meer en meer functionaliteiten moeten bezitten waardoor ze in verschillende toepassingen
gebruikt kunnen worden. Dit is moeilijk om in het begin van het project vast te leggen. Daarom gaat
dit probleem vaak gepaard met de afwezigheid van voldoende kritische stakeholders. Deze stakeholders
slagen er niet in om de vorderingen die gemaakt worden in het project te evalueren en al dan niet stop
te zetten. Het is de taak van de project manager om ervoor te zorgen dat het project wordt uitgevoerd
aan de hand van het initiele plan en de initieel gedefinieerde requirements en objectieven. Alles wat
aangepast wordt, moet expliciet gedocumenteerd worden en worden voorgelegd aan de klant. Het is
mede de taak van de project manager om hierop toe te zien.
Wysocki wijst ook nog op drie andere fenomenen die een fataal karakter zouden kunnen hebben op
het project. Een eerste is hope creep. Dit doet zich voor wanneer de leden van het project team
achter lopen op schema maar rapporteren dat ze perfect op schema zitten omdat ze denken dat ze
tegen de volgende deadline de achterstand goed gemaakt zullen hebben. De project manager wordt in
dit geval misleid door zijn eigen team. Wanneer dit bedrog aan de oppervlakte komt en desastreuze
4
gevolgen heeft, zal het vertrouwen van de klant of sponsor op het volledige team wegvallen. Om de
accuraatheid van de statusrapporten te verifieren, en dus eventueel project falen te vermijden, kan
de project manager willekeurig de rapporten controleren. Een ander fenomeen is de effort creep. Dit
doet zich voor wanneer het project geen proportionele vooruitgang maakt ten opzichte van het werk
dat nog gepland staat. Het kan goed zijn dat de wekelijkse statusrapporten vooruitgang melden,
maar dat het werk dat nog rest niet proportioneel is afgenomen. Het team is dan niet in staat om
de werklast van de scope in te schatten, waardoor men geen goed beeld heeft op het budget en tijd
die uiteindelijk nog nodig zullen zijn om het project te voltooien. Een laatste illustratie is de feature
creep. Dit is sterk gerelateerd aan de scope creep. Het doet zich voor wanneer de teamleden functies
of functionaliteiten toevoegen die niet met de sponsor of klant werden overlegd maar waarvan gedacht
wordt dat hij ze wel zal willen. Dit fenomeen wordt ook Gold Plating genoemd. Algemeen heeft het
een negatief karakter. Het zorgt ervoor dat er meer ongedocumenteerd werk gedaan wordt dat buiten
de scope van het project valt. De oplossing is eenvoudig. Als de functionaliteit zich niet bevindt in
het initieel opgestelde document, moet een formele change request worden ingediend ter goedkeuring
van de extra functie, hoe triviaal deze ook mag zijn.
2.1.1 Principes van Klassiek PM
In deze sectie zullen we gebruik maken van de Project Life Cycle van PMBOK om zo de principes van
het klassiek projectmanagement toe te lichten. Een PLC houdt de verschillende fasen in die achter-
eenvolgens of soms ook iteratief worden doorlopen in een project. Het heeft als doel de complexiteit
van het project te reduceren door het op te delen in de verschillende fasen zodat het makkelijker wordt
om te managen. Het moet gezien worden als een drill-down van het project in verschillende kleinere
afgelijnde fasen die makkelijker te managen zijn. In de PMBOK worden deze fasen de procesgroepen
genoemd. Een groot project kan ook worden opgedeeld in verschillende subprojecten. Elk van die
subprojecten doorloopt de procesgroepen van de project life cycle. De PLC die wij gebruiken, bestaat
uit de volgende vijf procesgroepen(PMBOK, 2013).
Figuur 2: Project Life Cycle van PMBOK
5
(a) Initiatie van het project
In de initiatiefase wordt een nieuw project of nieuwe fasen van een bestaand project gedefinieerd.
Dit begint met de identificatie van bepaalde problemen of noden die zich binnen een bepaalde
organisatie stellen. Aan de hand hiervan wordt de scope opgesteld. Naast de scope wordt ook
het budget, dat beschikbaar gesteld wordt, vastgelegd. De initiator van dit denkproces kan een
sponsor, een senior manager, een klant, de PMO of het portfolio steering comite zijn. Hij identi-
ficeert het probleem en legt dit vast in het project charter. Dit is het document dat zal gebruikt
worden als leidraad gedurende het project. Voor de sponsor is dit charter een vertaling van zijn
engagement voor het project. Als van bij voorbaat geen project manager werd aangesteld, wordt
dit hier ook door de sponsor gedaan. Met het project charter geeft de sponsor de project manager
de autoriteit om de resources die hij nodig heeft aan te wenden. Dit geeft de project manager de
leiding over de samenstelling van het projectteam en de andere resources. Het project charter is
het bewijs dat het project effectief bestaat. Daarnaast heeft het ook een strategische taak. Het
project moet passen binnen de strategie van de organisatie. De structuur van het document is als
volgt:
Eerst is er de sectie met de algemene informatie betreffende het project. De naam van het project,
de naam van de sponsor organisatie en de naam van de persoon die de organisatie representeert
zijn enkele essentiele zaken die hier aan bod moeten komen.
Een volgend onderdeel is de identificatie van de stakeholders betrokken bij het project, samen
met hun functie en hun contactgegevens.
Vervolgens is er de korte samenvatting van het project. Dit wordt de executive summary ge-
noemd. Op basis van deze informatie moet het mogelijk zijn om een goed beeld te krijgen over
de algemene objectieven van het project en de nog te volgen stappen.
Daarna wordt de opzet van het project verduidelijkt. Dit wordt gedaan door zowel de huidige
noden in het bedrijf te identificeren als de objectieven die men wilt bereiken met het project. Zo
kan gekeken worden in welke mate het project voldoet aan deze vooropgestelde doelen. De ob-
jectieven zijn gelinkt aan de strategie en zorgen er dus voor dat, zoals eerder gesteld, het project
gelinkt is aan de globale strategie. Deze objectieven zijn nog te breed gedefinieerd om efficient mee
om te gaan in het project. Ze moeten door middel van een Work Breakdown Structure worden
ontleed in kleinere activiteiten waarmee makkelijker kan omgegaan worden. Dit komt terug in de
planningsfase, het kennisgebied van het scope management in de volgende alinea’s.
Een vijfde onderdeel is een overzicht van het project. Concreet houdt dit vier zaken in. Een eerste
6
is de projectbeschrijving. Dit is een verduidelijking van de focus, de aanpak, de klanten en de
limieten van het project. Een tweede element is de scope. Deze geeft een antwoord op vragen zoals
Wie? Wat? Waar? Wanneer en Hoe? van het project. Assumpties worden ook gedefinieerd.
Zaken die niet kunnen aangetoond worden, moeten hier duidelijk worden neergeschreven. Een
laatste onderdeel van het projectoverzicht zijn de constraints. Dit zijn de grenzen waarbinnen het
project moet opereren. Dit kan bijvoorbeeld gaan over een maximaal aantal resources dat het
project niet mag overschrijden.
Een volgende sectie betreft de requirements. Hier wordt zo volledig mogelijk opgesteld wat het
project moet bereiken. Deze requirements moeten duidelijk worden door middel van een gesprek
van de project manager met de sponsor. Dit onderdeel is extreem belangrijk aangezien er dikwijls
fouten ontstaan in de communicatie met de sponsor of de sponsor niet volledig is in het definieren
van de functionaliteiten waar de uitkomst van het project moet aan voldoen. De project manager
dient in deze fase te beschikken over voldoende ervaring zodat hij de juiste vragen kan stellen.
Dit is meteen ook de reden waarom senior project managers meestal de leiding krijgen over de
uitvoering van een project.
Verder worden de Project Management Milestones opgesteld. Dit zijn belangrijke mijlpalen in de
levensloop van het project die vooropstellen dat een bepaald onderdeel van het project tegen de
vooropgestelde datum afgewerkt moet zijn. Ook wordt hierbij vermeld wie verantwoordelijk is
voor deze mijlpaal.
Een ander onderdeel beslaat het budget en de kosten van het project. De doelen die eerder in het
project charter werden opgesteld, beslaan elk een deel van het budget dat voorhanden is en dat
wordt gefinancierd door de sponsor.
Ook het personeel en de andere resources worden vastgelegd. Net zoals het budget, kunnen de
resources nog veranderen naargelang de uitvoering van het project afhankelijk van de dynamiek
in de constraints van de Project Triangle. De andere resources kunnen materialen, voorzieningen,
software tools of andere specifieke zaken zijn.
Risico is ook een belangrijk onderdeel van het project charter. De risico’s waaraan initieel wordt
gedacht, worden hier opgelijst. Later kan dan een inschatting gemaakt worden met een bepaalde
factor van hoe sterk de kans is dat deze gebeurtenis zich zal voordoen.
Vervolgens wordt in het onderdeel Projectorganisatie het project voorgesteld door een Project
Organization Chart. Dit is een schematische voorstelling van de organisatorische structuur van
7
het project. Typisch staat de project sponsor helemaal bovenaan met er net onder de project
manager en de andere stakeholders. Van deze stakeholders worden dan de rollen en de verant-
woordelijkheden vastgelegd.
In het project charter kan ook verwezen worden naar andere bestaande documenten die informatie
bevatten die van toepassing zijn voor dit project. Als het project charter nog andere informatie
bevat dan deze die hier voorhanden is, wordt verwezen naar de specifieke documentatie.
Het laatste onderdeel is de ondertekening van het document door de partijen waarmee ze akkoord
gaan met wat in dit document wordt meegedeeld. Dit betekent ook meteen het einde van de
initiatiefase waarmee de volgende fase, de planning, kan worden aangevat.
(b) Planning van het project
Het project team doorloopt in een planning sessie verschillende fasen om een goede planning
van het project te bekomen. Typisch wordt vertrokken van een gedetailleerde bespreking van
het Project Charter dat werd opgesteld in de initiatiefase. Dit om duidelijkheid te scheppen
over de objectieven van het project. Het is de bedoeling om deze objectieven in de planning
te verfijnen. Dit kan gebeuren met behulp van een work breakdown structure. Hierin worden
de objectieven afgebroken tot activiteiten die makkelijker kunnen worden gecontroleerd. Het is
duidelijk dat dit een top-down aanpak is. Van de uit te voeren taken die worden bekomen, wordt
vervolgens een schatting gemaakt van de duur en de inspanningen die nodig zijn. De taakduur kan
geschat worden door onder meer historische data, advies van experten of door vergelijking met de
werklast van andere activiteiten. Een andere statistische methode is de PERT-methode.2 Deze
bestaat uit een formule om de duur van activiteiten te schatten. De duurtijden van de activiteiten
worden geschat door iemand die over een goede kennis beschikt omtrent de activiteiten. De tijden
worden door deze persoon geschat in elk van drie scenario’s: optimistisch, pessimistisch en meest
waarschijnlijk. Naast een schatting van de duurtijd, wordt ook een kans van optreden toegewezen.
Met behulp van deze data en de formule kan een inschatting gemaakt worden van de duur van
de activiteiten. Door de standaarddeviatie te berekenen kan ook het risico verbonden aan de
activiteit worden geschat.
2Program Evaluation and Review Technique, gepubliceerd door de U.S. Navy omstreeks 1950.
8
Figuur 3: PERT-techniek
In bovenstaande figuur stellen punten a, m en b respectievelijk het optimistische, meest waar-
schijnlijke en pessimistische scenario voor de inschatting van de duur van activiteiten. Volgens
onderstaande formules kunnen dan de tijd t en de standaardafwijking s geschat worden.
t = (a + 4m + b)/6 (1)
s = (b− a)/6 (2)
Op basis van deze schattingen, kan dan beslist worden hoeveel resources worden toegewezen
aan elke activiteit. Een volgend punt op de agenda is de ontwikkeling van een Project Network
Diagram. Hier wordt de volgorde van de activiteiten in kaart gebracht. De datum waarop de
activiteit kan starten en de vroegste datum waarop de activiteit moet afgelopen zijn, worden hier
meegegeven. Het kan ook voorkomen dat bepaalde constraints verbonden zijn aan verschillende
activiteiten. Dit heeft dan te maken met afhankelijkheid. Een bepaalde activiteit kan bijvoor-
beeld niet aangevangen worden vooraleer een andere is voltooid. Vervolgens kan het critical path
worden geıdentificeerd. Dit is het langst mogelijke pad dat kan gevormd worden door afhankelijke
activiteiten. Daarvoor moet een variabele, genaamd slack, worden berekend. De slack time is
de tijd waarmee een activiteit kan verschoven worden zonder een vertraging van het project te
veroorzaken. Het critical path is dan het pad dat gevormd wordt door de activiteiten die een
minimale slack time vertonen. Wanneer er echter resources worden toegevoegd, worden de zaken
veel ingewikkelder. Hiervoor kan de Critical Chain methode3 worden gebruikt. Deze methode
3Critical Chain Project Management (CCPM, ontwikkeld door Eliyahu M. Goldratt in zijn boek Critical Chain (1997)-
www.goldratt.co.uk.
9
wordt ook ondersteund in de PMBOK. Hier wordt het netwerk opgesteld waarin de activiteiten
zo laat mogelijk worden gepland. Dit zorgt ervoor dat er minder werk in de pijplijn blijft zitten
en de kosten ook niet te vroeg worden opgenomen. Naast deze voordelen op vlak van cash flow,
is het ook belangrijk dat de requirements beter kunnen worden gecapteerd. Deze kunnen immers
tot in een laat stadium van het project aangepast worden. Zoals ook in de andere methodes
voor projectmanagement die in dit werk worden behandeld, is dit een uiterst belangrijk gegeven.
Verder worden op verschillende punten buffers tussengevoegd met als doel de onzekerheid op te
vangen. De feeding buffers worden geplaatst wanneer een activiteit die niet op het kritieke pad
ligt, een activiteit voedt die wel deel uitmaakt van het kritieke pad. Op het einde van de keten
wordt nog een project buffer ingevoegd die de einddatum van het project moet veiligstellen.
Figuur 4: Example of the Critical Chain Method
Volgens Wysocki (2003) heeft het gebruik maken van de planning drie voordelen. Een eerste is de
reductie van onzekerheid. Hoewel het project nooit exact volgens de planning zal verlopen, geeft
het toch een mogelijkheid om de resultaten van het project in te schatten en te oordelen wanneer
moet ingegrepen worden als te sterk afgeweken wordt van het plan. Ook zorgt het ervoor dat de
doelen en de objectieven van het project duidelijk worden voor iedereen. Een laatste voordeel
volgens Wysocki is dat planning de efficientie verbetert. Vooral het plannen van de resources is
hier belangrijk. Het werk kan parallel worden gepland zodat de totale projectduur gevoelig kan
worden verminderd.
10
(c) Executie van het project
Deze fase houdt verband met het coordineren van mensen en resources, het managen van de
wensen van de klant en het uitvoeren van de activiteiten volgens het opgestelde projectplan. De
fase start met een kick-off meeting. Deze meeting doet zich slechts een keer per project voor en
gebeurt typisch nadat het projectplan is goedgekeurd, vooraleer er werk gedaan is. De sponsor
wordt voorgesteld, samen met de objectieven die willen bereikt worden. Vervolgens worden de
teamleden ook aan elkaar voorgesteld. De regels waarbinnen het team moet opereren worden ook
bekendgemaakt zodat het team duidelijk weet hoe het moet werken. Verder is het ook belangrijk
dat de teamleden weten hoe ze moeten communiceren. Het projectplan wordt dan ook finaal
aangepast aan de samenstelling van het team.
Op het moment van de kick-off meeting zijn ze nog geen team, enkel een groep. Velen zullen elkaar
voor de eerste keer ontmoeten en zijn vreemden voor elkaar. Daarom is het zo belangrijk dat in de
regels werd vastgelegd hoe het team moet werken. Dit kan gaan over de tijdsbesteding van de ver-
schillende teamleden aan het project en geeft dus een beeld over de beschikbaarheid. Deze eerste
ontmoeting kan ook belangrijk zijn voor het verdere verloop van het project. Teamleden moeten
zichzelf voorstellen en elkaar zo goed mogelijk leren kennen op een korte tijd. Vanaf dit moment is
het team operationeel en werken ze volgens het vooropgestelde plan. De voortgang die ze maken
wordt nauwlettend in het oog gehouden in de volgende stap, de toezicht- en controleprocessen.
Wanneer het team tijdens het project stuit op veranderingen in de scope, zal een formele change
requests moeten worden opgemaakt voor de klant waarin wordt beschreven welke impact deze
change zal hebben op de andere constraints in de project triangle. De planning kan dan telkens
geupdatet worden naargelang de verandering en haar impact op de andere constraints.
(d) Toezicht en controle
Hier wordt de voortgang en de performantie van het project gemeten. Verder wordt ook toezicht
gehouden op het risico. De resultaten van deze analyses worden gerapporteerd aan de opdrachtge-
ver zodat hij ten allen tijde de voortgang van het project kan volgen en dit ook kan meedelen aan
het management. Wanneer de opdrachtgever veranderingen in de scope wilt doorvoeren, moet dit
ook hier gebeuren. Dit kan een mogelijk pijnpunt zijn wanneer de opdrachtgever merkt dat het
project niet volledig loopt zoals gewenst en er nog additionele functionaliteiten of veranderingen
nodig zijn. Het is dan zijn taak om dit mee te delen aan de project manager en dit eventueel aan
het management mee te delen als er extra middelen nodig zijn. Er moet dan een terugkoppeling
11
gebeuren van de controle fase naar de planning fase. De planning moet aangepast worden aan de
additionele requirements en resources die nodig zijn. De aanpassingen die nodig worden, worden
in het jargon change requests genoemd. Deze update van de planning kan volgens Vanhoucke
(2013) op twee manieren gebeuren. Een eerste is de reactieve planningsmethode. Deze planning
houdt geen rekening met onzekerheid of potentiele risico’s. Tijdens de executiefase moet dan
worden gecontroleerd hoe groot de afwijkingen ten opzichte van de planning worden. Wanneer
deze uit de hand lopen, moet ingegrepen worden. Een tweede methode is de proactieve planning.
Hier wordt de onzekerheid al ingecalculeerd en worden buffers ingepland.
(e) Afsluiten van het project
Dit is de oplevering van het project aan de klant. De klant kijkt of de vooropgestelde wensen
effectief gehaald werden. Hier wordt het duidelijk of de initiele wensen werden nageleefd. In de
praktijk wringt hier meestal het schoentje. De klantwensen zijn niet altijd goed overgebracht naar
de project manager en het team. Dit kan liggen aan communicatie tussen beide of aan het feit
dat de opdrachtgever zelf niet duidelijk wist wat hij precies nodig had. Dit zou kunnen leiden tot
verspilling van geld en tijd. Wanneer de wensen van de klant wel voldaan werden, wordt een finaal
projectrapport opgesteld. Daarnaast kan ook verder onderhoud in de toekomst worden voorzien
indien de klant dit wenst.
In de procesgroepen worden de vele processen gebundeld naargelang hun doel. De processen die
hetzelfde doel delen, worden samengenomen in een procesgroep. Bijvoorbeeld de processen die nodig
zijn om het project charter op te bouwen, worden samengenomen in de initiatiefase. Een tweede
classificatie van deze processen kan gebeuren op basis van kennisgebied. De processen die behoren tot
eenzelfde kennisgebied, worden hierin samengenomen. De processen zijn verdeeld over tien dergelijke
kennisgebieden. De processen worden toegewezen aan een kennisgebied, dat in zijn geheel een compleet
professioneel domein vormt.
Een eerste kennisgebied is integratiemanagement. Dit zorgt ervoor dat het project een geheel vormt.
De aspecten van de elke fase moet in lijn liggen met de objectieven die men wenst te bereiken met het
project, vastgelegd in het project charter. De resultaten van de verschillende fasen worden samenge-
voegd tot een coherent geheel.
Een tweede item is het scope management. De documentatie van de wensen van de klant dient goed
nageleefd te worden in elke fase. Een goeie manier om dit te doen is door een Work Breakdown Struc-
ture op te stellen die het werk definieert om aan de wensen te voldoen. De objectieven worden zoals
12
eerder gesteld opgedeeld in kleinere activiteiten die dan kunnen worden gepland. Dit proces, gaande
van objectieven naar activiteiten wordt in totaal opgedeeld in vier niveaus. Een eerste niveau betreft
de project objectieven. Deze worden gespecifieerd in work items. Dit heeft als doel de complexiteit
van het project te reduceren. Verder wordt overgegaan naar work packages. Dit is een verzameling
van activiteiten waarbij data met betrekking tot de kosten wordt bijgehouden. De activiteiten zijn
het laatste niveau van de WBS waarbij de kosten, duurtijden en relaties tussen de activiteiten kunnen
worden verduidelijkt. Deze WBS wordt schematisch weergegeven in volgende figuur.
Figuur 5: Work Breakdown Structure (Vanhoucke, 2013)
Het managen van tijd is ook een belangrijk aspect. Dit houdt twee componenten in, een planning
component en een controle component. In de planning component schat men de duurtijd die nodig
is om de taak te vervolledigen en de effectieve werktijd die nodig is om de taak af te werken. De
duurtijd wordt gebruikt om de totale tijd te schatten die nodig zal zijn om het project af te werken.
De werktijd wordt gebruikt om de totale kost van arbeid te schatten. De controle component is een
onderdeel van de toezicht- en controlefase van het project en is erop gericht de geschatte tijden te
vergelijken met de effectieve voortgang van het project.
Naast tijd management is ook kost management een belangrijke factor. Hier is er ook een planning
en een controle component die er respectievelijk op gericht zijn om het budget te schatten en de
variantierapporten te maken.
13
Als vijfde element is er de kwaliteit. Kwaliteit wordt gemeten door middel van een kwaliteitspro-
gramma dat typisch bestaat uit drie verschillende onderdelen. Eerst is er de planning die standaarden
vooropstelt waar het product zou moeten aan voldoen. Vervolgens is er de kwaliteitszorg. Dit zorgt
ervoor dat de kwaliteit volgens plan verloopt. Als laatste is er de kwaliteitscontrole die kijkt of er
effectief is voldaan aan de kwaliteitsstandaarden aan de hand van tools, checklists en processen. Bij
het kwaliteitselement is het belangrijk dat het product voldoet aan de vooropgestelde criteria van de
klant. Wanneer het hieraan voldoet, kan het worden overgeleverd aan de klant en kan hij ermee werken
en zien of er iets moet aangepast worden. Dit wordt benoemd als fit for use.
Beweren dat een project manager enkel het werk moet verdelen, zou een grote vergissing zijn. De
project manager is in de eerste plaats een HR manager die zorgvuldig het team samenstelt en beoordeelt
of de vaardigheden van het team voldoende zijn om het project tot een goed einde te brengen. De
functionele manager wijst personen toe aan het team en het is dan aan de project manager om
te beoordelen waar deze persoon, gezien zijn competenties, het beste tot zijn recht zal komen in
het project. Het is dus een wisselwerking tussen de functionele manager en de project manager.
De project manager is verder ook een belangrijke schakel in de motivatie van het team. Hij moet
een omgeving creeren waarin het aantrekkelijk is om te werken. Volgens Herzberg (1959) hebben
motivatoren en zogenaamde hygienefactoren hierin een groot aandeel. Motivatoren zijn zaken die
een positieve impact hebben op de prestaties van de teamleden. Hierin onderscheidt hij het werk
zelf, de mogelijkheid om te groeien, verantwoordelijkheid, erkenning en succes. Hygienefactoren zijn
zaken die een negatieve invloed hebben op de prestaties als ze niet aanwezig zijn. Hieronder vallen
het bedrijfsbeleid, werkomstandigheden, relaties met de collega’s, werkzekerheid, salaris, toezicht en
relatie met leidinggevende. Wanneer deze zeven factoren niet aanwezig zijn, zullen ze acteren als
demotivatoren voor de werknemers.
Naast de HR-functie van de project manager, is er ook nog het communicatiemanagement. Volgens
Wysocki (2003) is 70% van het projectfalen toe te wijzen aan slechte communicatie. Om communicatie
goed te leiden moet er vooreerst duidelijkheid zijn omtrent de stakeholders van het project. Wie heeft
er baat bij de communicatie rond het project? Een tweede belangrijk aspect is de informatie die moet
gekend zijn rond het project. Het moet duidelijk zijn wat met welke personen moet worden gedeeld.
Niet elk detail moet worden gedeeld met de projectverantwoordelijke. Dit zou op termijn kunnen
leiden tot een informatie-overload. Daarnaast is de manier van communicatie ook afhankelijk van hoe
tegemoet moet gekomen worden aan de noden van de ontvanger.
14
Een volgende kennisgebied dat dient onderzocht te worden is het risicomanagement. Het risico moet
eerst geıdentificeerd worden. Het team wordt hiervoor samengebracht in een vergadering. Dergelijke
meeting zou moeten georganiseerd worden met risico als enige onderwerp. Zo wordt het duidelijk voor
het team dat risico een belangrijk aspect is dat veel aandacht verdient.(Wysocki, 2003) Typisch worden
er vier mogelijke bronnen van risico onderzocht. Dit zijn de technische risico’s, de projectmanagement
risico’s, risico’s met betrekking tot de organisatie en externe risico’s. Deze risico’s worden dan beoor-
deeld naargelang de graad van belangrijkheid. Dit kan gedaan worden door de kans te berekenen dat
het risico zich zal voordoen of door te bekijken welke impact het voorval zal hebben op het project.
Verder dient ook opgesteld te worden welke actie zal ondernomen worden als het risico zich effectief
voordoet. Een laatste taak die hier moet gebeuren is de controle. De risico’s moeten neergeschreven
en gedeeld worden met het volledige projectteam. Deze risico’s kunnen worden opgeslagen in een risk
log.
Het kennisgebied met betrekking tot het aankoopmanagement is het laatste dat dient onderzocht te
worden. Elk project dient gebruik te maken van externe leveranciers. Dit aspect moet dan ook grondig
overwogen worden. Eerst wordt opgesteld wat het project juist nodig heeft van een leverancier. Dit
wordt duidelijk vastgelegd in een document, een request for proposal dat gebruikt wordt om aan de
leverancier duidelijk te maken wat hij zou moeten leveren. De leverancier zal dan een offerte geven
voor de gewenste producten of diensten. Het is ook belangrijk om de leverancier te evalueren op basis
van technische ervaring, kost of andere criteria. Op basis van de offerte en de evaluatie wordt dan
een leverancier gekozen en wordt een contract opgesteld. Dit contract houdt in dat de leverancier
de goederen dient te leveren voor een bepaalde datum. De project manager zal op regelmatige basis
meetings houden met de leverancier om de vooruitgang van het product te bespreken. Alle informatie
betreffende de deal moet bijgehouden worden door de project manager en duidelijke afspraken dienen
gemaakt te worden met betrekking tot het einde van de samenwerking.
Een tiende kennisgebied is het stakeholder management. Dit werd pas toegevoegd in de vijfde editie van
de PMBOK in 2013. De verwachtingen en behoeften van elke stakeholder moeten worden onderzocht.
2.1.2 Frameworks voor Klassiek PM
Zoals eerder gesteld is een veelvuldig toegepast framework voor klassiek projectmanagement de Project
Management Body of Knowlegde, ontwikkeld door PMI, dat zijn wortels heeft op Amerikaanse bodem.
De tegenhanger van de PMBOK is PRINCE2, wat staat voor PRojects IN Controlled Environments.
PRINCE2 is een methode die ook toepasbaar is voor projectmanagement van verschillende types
15
projecten. Wel kan gesteld worden dat het vooral de nadruk legt op projecten in een informatica
omgeving. PRINCE2 kent zijn oorsprong in de Britse overheidsorganisatie OGC. In tegenstelling
tot de PMBOK maakt PRINCE2 gebruik van zes processen, gaande van de start van een project
tot het afsluiten van het project. Bijkomend zijn er twee processen, de planning en de executie, die
gedurende het project constant worden gemonitord en toegepast op elk proces waarin het project zich
bevindt. Op vlak van project levenscyclus en processen is dit het grootste verschil tussen beide. Op
vlak van management en rollen gebruikt PRINCE2 andere benamingen. Zo wordt de sponsor uit de
PMBOK hier executive genoemd. De rollen houden ongeveer hetzelfde in in beide frameworks, enkel
de benamingen verschillen soms. Op vlak van documentatie wordt er in PRINCE2 eerst een project
mandate opgesteld dat gedurende het start-up proces wordt omgevormd in een project brief. De output
van dit proces is het Initiation Stage Plan dat alles beschrijft wat ook in het Project Charter van de
PMBOK wordt beschreven (Wildeman, 2002).
Wij hebben ervoor gekozen om de methode van PMI te gebruiken in onze thesis aangezien deze
ook de meest gebruikte methode is die algemeen kan worden toegepast. Onderstaande figuur is het
resultaat van een studie, uitgevoerd door PricewaterhouseCoopers in 2007, die kijkt naar de verdeling
van gebruikte frameworks om projecten te managen. Deze studie toont aan dat de meeste projecten
worden uitgevoerd door middel van een in-house ontwikkelde methode. Ze toont ook aan dat de
PMBOK algemeen meer gebruikt wordt dan PRINCE2.
Figuur 6: Distribution of frameworks used in projectmanagement (PWC, 2007)
16
2.1.3 Moeilijkheden met Klassiek PM
We hebben aangetoond dat klassiek projectmanagement strikt de sequentiele stappen die genomen
moeten worden vastlegt op basis van initieel gedefinieerde vereisten van de klant. Volgens Hass (2007)
volgt een project in realiteit dikwijls niet het vooropgestelde plan. Ook is het voor de klant moeilijk
om de lijst met vereisten op te stellen omdat ze zelf nooit volledig weten wat de volledige oplossing
concreet moet inhouden. Verder duidt Hass ook op het feit dat de bedrijfsprocessen complexer en
onderling verbonden zijn aan elkaar. Klassiek projectmanagement heeft daar moeilijkheden mee.
Cobb (2011) wijst er verder nog op dat de klassieke waterfall aanpak ervan uitgaat dat de bedrijfs-
omgeving stabiel is en de requirements niet zullen veranderen gedurende het project. Verder wordt
de assumptie gemaakt dat de klant perfect capabel is om de requirements te defnieren zonder dat
deze evenwel duidelijk zichtbaar zouden zijn. Ook zouden deze requirements perfect gedocumenteerd
moeten zijn zodat er geen interpretatiefouten kunnen ontstaan door het ontwikkelingsteam. Deze as-
sumpties lijken niet echt realistisch vandaag de dag. Bedrijven die de waterfall aanpak toepassen, zien
dit als een manier om hun kosten en hun tijdsplan onder controle te houden. Deze zaken zijn echter
heel onzeker wanneer de requirements niet voor 100% duidelijk vaststaan. Gedurende het project zal
het moeilijk zijn om de requirements aan te passen aan de noden van de klant die evolueren naarmate
de vooruitgang die gemaakt wordt in het project. Het project kan dan wel voldoen aan de kosten en
het tijdsplan, maar de derde hoek van de project triangle wordt niet voldaan, met name de scope.
Het andere scenario is wanneer de klant vrij zijn wensen mag meedelen gedurende het project en het
project dan ook wordt aangepast. In een omgeving waar deze requirements onzeker zijn, kan dit leiden
tot vele onnodige change requests en het tenietdoen van de initiele plannen met betrekking tot het
budget en de tijd. Onderzoek van The Standish Group in de Verenigde Staten in 2006 heeft erop
gewezen dat 46% van de IT-projecten over tijd en budget opgeleverd werden en 19% van de projecten
faalden. Slechts 35% van de projecten werden met succes beeindigd. Dit wordt weergegeven in de
volgende figuur.
17
Figuur 7: Verdeling van slagen van IT projecten in de VS in 2006 (The Standish Group)
De reden van het overschrijden van tijd en budget kan liggen in het sequentiele verloop van het project.
Het product wordt pas op het einde getest, wat ertoe leidt dat heel veel tijd en geld worden gespendeerd
aan deze activiteiten die initieel niet voorzien werden. Andere methodologieen voorzien beter in dit
aspect maar boeten dan in op vlak van het inschatten van tijd en budget.
18
2.2 Lean PM
Lean projectmanagement is de algemene samenvoeging van allerlei Lean concepten in de context van
projectmanagement. Lean PM is een aanpak op lange termijn die ernaar streeft om kleine, incrementele
veranderingen in processen te verwezenlijken met als doel de efficientie en kwaliteit te verbeteren. Deze
benadering van PM ondersteunt het concept van continue verbetering en heeft als hoofddoel het streven
naar meer waarde en minder verspillingen. De meeste project managers beslissen om voor Lean te
kiezen wanneer ze geconfronteerd worden met bezuinigingen of andere beperkingen.
Lean PM komt voort uit Lean Manufacturing of Lean Production. Lean manufacturing wordt door
consultants vaak voorgesteld als een huis, dat een aantal concepten van Lean aan elkaar koppelt.
Het huis staat op een fundament, dat de robuustheid en stabiliteit van het systeem representeert.
Tenminste een werknemer beschikt de vaardigheden om alle taken op te volgen. De andere werknemers
beheersen ten minste de kennis om een taak uit te voeren. De basis van het Lean productie-systeem
ligt hierboven met een gestandaardiseerde werkomgeving (5S) aan de ene kant en continue verbetering
(Kaizen) aan de andere kant.
Vervolgens hebben we de twee pijlers: verbetering van het productieproces en reactie op afwijkin-
gen van het systeem. Heijunka, Takt Time Pull flow en JIT - Just in time - worden gebruikt om het
productieproces te verbeteren. Heijunka is een Japanse term die verwijst naar een systeem om produc-
tienivellering te bereiken en zo een meer consistente flow in de productie te brengen. De pullproductie
synchroniseert de productieketen doordat de producten door de logistieke keten worden getrokken.
Just in time beheerst de voorraad met als bedoeling levering en productie zo goed mogelijk op elkaar
af te stemmen. De tweede pijler bestaat uit het reageren op afwijkingen van het systeem waarvoor
stardardized work, man-machine separation en Jidoka wordt gebruikt. Standardized work is een tech-
niek om de variabiliteit van werkprocessen te verminderen. Man-Machine separation zorgt ervoor
dat een operator verschillende machines kan managen. Jidoka heeft als doel defectenvrij produceren.
Mens en machine beschikken over de autonomie om een stop te activeren zodra afwijkingen worden
geconstateerd.
In het dak van het ’Lean House’ staan de objectieven van Lean Manufacturing: lagere productiekosten,
betere kwaliteit en kortere levertijden. Het toepassen van al deze concepten resulteert dus in een
kwalitatief hoogstaand productieproces met korte levertijden en lage productiekosten.
19
Figuur 8: House of Lean
2.2.1 Principes van Lean PM
(a) Elimineren van verspillingen - verwijder alle non value added activities
Het definieren van de verschillende soorten van verspillingen die in een proces kunnen optreden
is zeer belangrijk. Aangezien verspilling alles is wat geen waarde toevoegt en elke vertraging die
klanten ervan weerhoudt waarde te krijgen, moeten we eerst weten wat waarde juist is. In de
hedendaagse bedrijfswereld heeft waarde de gewoonte om te veranderen, omdat gebruikers vaak
niet weten wat ze echt willen. Daarbovenop, eens het nieuwe project in werking is, zal hun idee
over wat ze juist willen voortdurend veranderen. We onderscheiden 9 categorieen van verspil-
lingen: transport, inventaris, materiaal bewegingen, wachttijden, overspecificatie, overproductie,
defecten/rework, creativiteit en energie. Lean teams hechten veel meer waarde aan de projectcy-
clus en de verschillende processen dan de traditionele project teams. Aan de hand van het Work
Breakdown Structure kijkt de Lean project manager hoe de verbindingen tussen teamgenoten hun
impact hebben op de kwaliteit en de prestaties.
Een ander belangrijk topic is dat de verkregen data worden gebruikt voor verbeteringen in de
toekomst en niet om fouten in het verleden aan iemand of een bepaald team toe te wijzen. Project
20
managers moeten zich voornamelijk focussen op de bottlenecks en proberen deze te elimineren
binnen hun teams. Op deze manier bouwen ze een duurzaam voordeel uit voor toekomstige
projecten met dezelfde verbeterde processen.
Dit lichten we toe aan de hand van een situatie in de software-ontwikkeling sector. Binnen de
software ontwikkeling is overspecificatie de grootste bron van verspilling. Volgens een onderzoek
van ‘The Standish Group’ worden slecht 20% van alle kenmerken en functies in de custom software
regelmatig gebruikt. Ongeveer 30% wordt niet frequent gebruikt, maar draagt wel nog bij tot het
project. Tot slot gebruikt men 50% van alle kenmerken en functies zelden of nooit. Hierbij
gaat het niet om belangrijke beveiligingsfuncties, maar over zaken die eigenlijk niet noodzakelijk
waren in de eerste plaats. De ontwikkeling van al deze extra functies brengt een grote kost en
complexiteit met zich mee. Hierdoor stijgt de onderhoudskost en daalt de levensduur van het
software systeem. Ongebruikte code vereist onnodige ondersteuning en documentatie. Er is nood
aan een proces dat toelaat om 20% van de code te schrijven die 80% van de waarde levert en
daarna te starten met de ontwikkeling van de resterende belangrijkste functies. Deze resultaten
kaderen binnen het denkproces van de project sponsor met betrekking tot het definieren van de
objectieven. Er moet geevalueerd worden of de activiteiten wel degelijk waarde toevoegen aan het
proces om de objectieven te bereiken.
Figuur 9: Onderzoek van ‘The Standish Group’ naar het gebruik van functies in de custom software
applicaties
21
De objectieven van de project manager zijn andere dan deze van de project sponsor. De project
manager wordt gevraagd om het project uit te voeren in zo weinig mogelijk tijd en met zo weinig
mogelijk budget. Alle onnodige activiteiten moeten worden geschrapt om een zo lean mogelijk
proces te krijgen.
(b) Bouw kwaliteit in
Het absolute doel is om van bij de start kwaliteit in de code te bouwen, niet om het nadien
te testen. Het is de bedoeling om je proces zodanig aan te passen dat fouten maken niet meer
mogelijk is. Dit is veel efficienter dan het ontwikkelen van een opsporingssysteem voor defecten.
Volgens Shigeo Shingo bestaan er twee soorten inspectie: inspectie nadat defecten zijn opgetreden
en inspectie om defecten te voorkomen. De eerste categorie moet absoluut vermeden worden.
Indien dit niet mogelijk is, dan inspecteer je het product na iedere kleine stap in het proces,
zodat defecten onmiddellijk zichtbaar worden wanneer ze zich voordoen. Wanneer een defect is
gevonden, stop je het proces, zoek je de oorzaak en repareer je het onmiddellijk.
In de software ontwikkeling wordt dit principe goed toegepast. Het ontwikkelen en testen van
de code wordt samen geıntegreerd in een run. Telkens er nieuwe code wordt geschreven, testen
ze op fouten. Er wordt geen nieuwe code toegevoegd vooraleer alle foutieve code is verwijderd.
Organisaties die deze manier van werken hanteren, rapporteren extreem lage defect ratio’s en zeer
korte tijdsintervallen voor het vinden van de oorzaak voor defecten.
(c) Empowerment, respect en integriteit
Empowerment wordt verkregen door middel van zelfsturende teams die zelf beschrijven wat nodig
is en hoe ze het proces zullen aanpakken. Belangrijk hierbij is wel dat je beschikt over capabel en
getraind personeel. Door teams deze verantwoordelijkheid te geven, creeer je een grotere inzet en
betrokkenheid. Doordat Lean PM het geheel opsplitst in subprojecten met een kleinere impact
op het resultaat, is het falen van dergelijk subproject minder erg dan wanneer een groot project
in elkaar stort. Belangrijk is dat men leert uit gefaalde projecten uit het verleden en dit ziet als
een signaal tot verbetering.
(d) Later beslissen en sneller leveren
Lean project managers verfijnen de omvang van hun projecten doordat ze zo lang mogelijk alle
onomkeerbare opties open houden en wachten tot het laatste moment om concrete plannen te
vergrendelen. Door deze verschillende opties zolang mogelijk open te houden, profiteren de teams
22
van nieuwe creatieve ideeen. Niet alle beslissingen moeten echter uitgesteld worden. Eerst en
vooral moet men proberen zoveel mogelijk beslissingen omkeerbaar te maken, zodat men ze kan
plannen en makkelijk veranderen.
Verder dwingen ze hun teams om grote projecten te reduceren tot verschillende kleinere, haalbare
deelprojecten die efficienter kunnen worden gepland. De teamleden hebben door deze aanpak
meer zelfvertrouwen en een sterker gevoel van vervulling, omdat er regelmatig een deelproject
wordt voltooid. Grote projecten demotiveren teams en ze krijgen het gevoel dat het project niet
zal slagen, omdat men de vooruitgang nauwelijks merkt.
Als organisatie moet je de bekwaamheid hebben om te wachten met beslissen tot bepaalde ge-
beurtenissen plaatsvinden. Wanneer men dan vervolgens snel en correct reageert, dan zullen deze
organisaties betere resultaten genereren dan degene die proberen om de toekomst te voorspellen.
Plannen is echter niet hetzelfde als het nemen van een beslissing. Eerst moet men alles zorgvuldig
plannen en vervolgens spaarzaam beslissen.
(e) Versterken van het leerproces
Bij Lean PM is het belangrijk dat je ook training voor je team voorziet in de Work Breakdown
Structure. Deze training is extra belangrijk voor nieuwe en unieke projecten waar je teams niet
mee vertrouwd zijn. Op deze manier bereid je ze voor op de onbekende toekomst. Succesverhalen
van teamleden die hun capaciteiten succesvol verbeterden, moedigen vaak andere collega’s aan
om te starten met hun eigen professionele ontwikkeling. Op deze manier creeer je uitzonderlijke
sterke teams die zeer hoge kwaliteit kunnen genereren. Verder is het belangrijk dat de nieuwe
kennis beknopt wordt samengevat, zodat ze toegankelijk is voor de grotere organisatie.
Alan MacCormack, professor aan de Harvard Business School, bestudeerde in 2003 de manier
waarop organisaties omgaan met leren. Tijdens zijn onderzoek vroeg een bedrijf aan hem om
twee projecten te evalueren: een ‘goed’ en een ‘slecht’ project. Het ‘goede’ project was verlo-
pen zoals gepland. Het ontwerp was geoptimaliseerd en de resultaten leunden dicht aan bij de
initiele specificaties. Het ‘slechte’ project onderging voortdurend vernieuwingen omdat het team
problemen had met de constante veranderingen in de markt. Het ‘goede’ project scoorde slecht
op kwaliteit, productiviteit en werd niet geaccepteerd door de markt, terwijl het ‘slechte’ project
een succes was. Het is niet verwonderlijk dat het team dat leerde tijdens de ontwikkeling, een
beter product creeerde.
23
(f) Optimaliseer het volledige proces
Gantt diagrammen zijn een handige tool om naar het volledige geheel van projecten te kijken.
Door verschillende keren per jaar door de cyclus van een project te gaan, kunnen project managers
reageren op nieuwe eisen van klanten. Taken die geen waarde meer bijbrengen voor de klanten
moeten zoveel mogelijk worden verwijderd, zodat de teams deze tijd opnieuw nuttig kunnen in-
vullen met waardetoevoegende activiteiten.
2.2.2 Frameworks voor Lean PM
Project managers die gebruik maken van klassiek projectmanagement zijn er zich bewust van dat
deze aanpak verschillende tekortkomingen heeft in de ontwerp- en executiefase. De problemen in
deze fasen kunnen zich voordoen op vlak van overschrijdingen van het budget, projectvertragingen en
kwaliteitsproblemen. Verschillende case studies hebben aangetoond dat een zwak ontwerp en slechte
documentatie de twee voornaamste redenen zijn voor een vermindering van de kwaliteit en de ef-
ficientie tijdens constructieprojecten. Traditionele constructieprojecten kunnen worden gekenmerkt
door vertragingen, kostoverschrijdingen, rework, ’change order’ aanvragen en geschillen met de klant.
Het ’Lean Project Delivery System’ (LPDS) biedt een oplossing tegen deze tekortkomingen in con-
structieprojecten en verbetert de volledige ontwerp- en executiefase (Ballard & Howell, 2003). Bij
traditioneel PM zijn de taken van de ontwerper en uitvoerder van elkaar gescheiden. LPDS ziet de
activiteiten van deze twee professionals als een onderdeel van projectmanagement om de volgende drie
doelstellingen te bereiken (Koskela, 2000):
� Afleveren van het project
� Maximaliseren van de waarde
� Minimaliseren van de verspillingen
Door de samenwerking tussen beide personen kan veel verspilling ontstaan. Verschillende onnodige
activiteiten of communicatie kunnen worden geelimineerd wanneer de personen nauw gaan samenwer-
ken en een gezonde discussie onderhouden. Verder hecht LPDS veel belang aan de implementatie van
de volgende drie principes van Lean PM:
� Respect, integriteit en samenwerken
Samenwerken overwint de versnippering tussen de ontwerp- en executiefase. Het verschil in ver-
wachtingen van de ontwerpers, uitvoerders en opdrachtgevers leidt tot zwakke constructiemoge-
24
lijkheden en slechte kwaliteit. Het actief nastreven van een relatie tussen teamleden bevordert
vertrouwen en openheid, die essentieel zijn voor groei. Een gebrek aan vertrouwen verhoogt de
projectduur en compliceert de coordinatie.
� Het versterken van het leerproces door actie
Het LPDS stelt voor dat werk wordt uitgevoerd op een manier waardoor de resultaten van
specifieke acties makkelijk waargenomen kunnen worden. Tekortkoming moeten snel worden
opgespoord, zodat men corrigerende acties kan ondernemen. Uit eerder ervaringen moet men
lessen trekken voor de continue verbetering van het plannen en de waarde van het volledige
project.
� Optimaliseer het volledige project en niet enkel subprocessen
Focussen op hoge productiviteit op taakniveau kan de snelheid en lokale prestaties maximaliseren,
maar vermindert de voorspelbaarheid van werk die later wordt vrijgegeven. Project optimalisatie
houdt in dat projectteams samenwerken om oplossingen te identificeren en te implementeren, in
tegenstelling tot alleen maar rekening te houden met de verschillende eigenbelangen. Deze aan-
pak voorkomt conflicten tussen de verschillende fases en kan de implementeerbaarheid verhogen
met 25 tot 30% (Drucker, 1999).
Het ‘Lean Project Delivery System’ (LPDS) bevat een aantal fases die behoren tot de basis van het
klassieke projectmanagement. De verschillende fases worden voorgesteld door overlappende driehoeken
om aan te tonen dat ze elkaar beınvloeden. Verder toont de overlap van de verschillende driehoeken
aan dat communicatie tussen de verschillende stakeholders noodzakelijk is. Iedere fase heeft namelijk
impact op de volgende fase en wordt beınvloed door de vorige fase. De verschillende fases zijn:
1. Project Definition
2. Lean Design
3. Lean Supply
4. Lean Assembly
5. Use/completion
25
Figuur 10: Het Lean Project Delivery System (LPDS)
Project Definition
Het doel van de eerste fase, Project Definition, is een beter begrip van het project te krijgen. Deze
initiele fase bevat dan ook een verantwoordelijke van ieder stadium in de levenscyclus van het project,
inclusief leden van het productieteam die instaan voor de ontwerp- en executiefase van het project.
Tijdens deze fase worden de scope (het doel), de middelen (wat noodzakelijk is voor de uitvoering)
en de constraints (locatie, tijd en kosten) verduidelijkt door middel van conversatie. De stap ‘Design
Concept’ zorgt ervoor dat de interesses van de stakeholders worden gematcht met de waarden, criteria,
concepten en specificaties van het project. Verder verbindt deze stap ook de eerste twee fases van het
LPDS.
Lean Design
De brug tussen ‘Project Definition’ en ‘Lean Design’ is het op elkaar afstemmen van waarden, con-
cepten en criteria. ‘Lean Design’ verloopt ook door middel van communicatie, ditmaal gewijd aan
de ontwikkeling en aanpassing van product- en procesontwerp. ‘Lean Design’ verschilt van de tradi-
tionele aanpak aangezien het beslissingen uitstelt tot het laatste moment zodat er meer tijd is voor
het ontdekken en ontwikkelen van nieuwe alternatieven. De uiteindelijke besluiten worden genomen
26
met een focus op het maximaliseren van waarde voor de klant en het minimaliseren van verspillingen.
Indien er tijdens het gesprek nieuwe opportuniteiten ontstaan, dan kan het project terug naar ‘Project
Definition’ gaan.
Lean Supply
De ‘Lean Design’ fase gaat over in de ‘Lean Supply’ fase. Op basis van het product design zal een
gedetailleerd engineeringsontwerp gemaakt worden. Dit ontwerp bevat alle studies die moeten worden
uitgevoerd alvorens men kan starten met de bouw van het project. Het bevat schema’s en tekeningen
voor de bouw, instrumentatie, controle-systeem, elektrische installaties, het beheer van leveranciers,
planning van activiteiten, de kosten, de aanschaf van apparatuur, economische evaluatie en ook de
milieueffecten voor aanvang van de bouw van een project. Kortom, aan de hand van dit ontwerp heeft
men alle informatie omtrent het produceren en leveren van componenten en materialen. Deze fase
omvat een logistiek concept om de inventaris en de doorlooptijd te verminderen.
Lean Assembly
‘Lean Assembly’ gaat verder met het leveren van informatie, componenten en materialen, alsook de
gereedschappen, machines en arbeid voor de installatie. Tijdens deze fase worden de bouwactiviteiten
uitgevoerd op het laatste mogelijke moment om veranderingen en nabewerking te vermijden. Na de
installatie eindigt deze fase met de ingebruikname en het gebruik van het project.
Use/Completion
De laatste fase bestaat uit de waarden van de eindgebruiker. Men moet van bij de start van het
project rekening houden met de informatie over de werking, het onderhoud, de verbouwingen en de
ontmanteling. Enkel op deze manier kan men voldoen aan de eisen van de eindgebruiker en hem een
lagere Total Cost of Ownership leveren. Om de waarde van het project te maximaliseren is het dus
zeer belangrijk om rekening te houden met deze fase. Een traditionele projectoplevering beschikt vaak
niet over deze fase, waardoor de eindgebruikers ontevreden zijn.
Elke fase omvat ‘Work Structuring’ en ‘Production Control’. ‘Work Structuring’ heeft als doel om een
betrouwbare workflow te creeren door het werk in kleinere delen te verdelen. ‘Production Control’
richt zich op de workflow en de productie-eenheden en maakt gebruik van vooruitziende processen
om ze te managen. Het doel van ‘Production Control’ is de uitvoering van de plannen en niet de
27
detectie van variantie. Tot slot integreert LPDS een ‘Learning Loop’ om te leren uit de projecten en
het systeem aan te passen bij elke stap en fase wanneer het nodig is.
Zoals voorgaand werd beschreven, volgt een project volgens de Lean aanpak eerder een sequentieel
verloop. Denyer, Kutsch & Lee-Kelley (2011) wijzen erop dat het principe van Lean om slack time te
verminderen ertoe leidt dat het project fragieler zal worden. Het verminderen van slack leidt immers
tot minder flexibiliteit en zorgt er dus voor dat er minder tijd is om na te denken en te experimenteren.
Dit impliceert dan weer dat het lerende aspect beperkt zal zijn en de verbetering in performantie de
kop kan ingedrukt worden.
2.2.3 Moeilijkheden met Lean PM
Binnen Lean PM wordt gebruik gemaakt van teams. Ideaal bestaat een team uit zo’n 8 a 10 personen
die complementair zijn aan elkaar, maar dit kan oplopen bij zeer grote projecten. Het project is
dus sterk afhankelijk van de samenhang van het team en de individuele taken van de teamleden.
Gemotiveerde professionele en geschoolde werknemers zijn nog sterker aanbevolen dan in een klassieke
omgeving, want een gebrek van deze professionals kan leiden tot een lage kwaliteit van het eindproduct
(Mossman, Ballard & Pasquire, 2010). Binnen het team moet de verantwoordelijkheid van ieder
individu duidelijk zijn om zo de kans op free-riding en miscommunicaties te minimaliseren.
Naast de samenstelling van de teams is er binnen Lean PM volgens critici ook nog een extra moeilijkheid
om het team gemotiveerd te houden. De constante focus van Lean PM op incrementele verbeteringen
en het verwijderen van verspillingen zou volgens hen heel wat stress veroorzaken op de werkvloer. Ze
beweren dat Lean voor een onpersoonlijke werkplek zorgt waar werknemers onder grote druk staan
om steeds beter te presteren. Als organisatie heb je dus de moeilijke opdracht om je werknemers
gemotiveerd te houden terwijl ze de focus van Lean PM niet uit het oog verliezen. Empowerment,
respect en integriteit kunnen hierbij helpen.
Een derde aandachtspunt treedt op bij het gebruik van LPDS die gebruik maakt van Just In Time en
Six Sigma voor het beheren van hun inventaris. Deze twee Lean-technieken laten geen safety stocks
toe waardoor er geen ruimte is voor afwijkingen van het optimale proces. Door externe factoren is
deze volmaakte situatie niet altijd mogelijk. Zo kunnen files bij een JIT-systeem ervoor zorgen dat de
productie gedurende een bepaalde tijd niet mogelijk is omdat er geen stock meer is. Ook de afwijzigheid
van werknemers door ziekte zou tot problemen kunnen leiden (Cusumano, 1994). Wanneer men dus
het volledige proces probeert te optimaliseren, mag men niet vergeten enkele scenario-analyses te
28
doen. Als we deze opmerking vertalen naar Lean in projectmanagement, kan dit ook in deze context
tot problemen leiden. De activiteiten in het projectplan worden zo laat mogelijk gepland en de slack
time wordt geminimaliseerd. Dit impliceert dat dit proces serieus inboet aan flexibiliteit.
Een laatste moeilijkheid treedt op doordat Lean PM zo laat mogelijk beslist. Door zo laat mogelijk
te beslissen, blijven verschillende opties open en zijn er minder change requests van de klant. Deze
afwachtende houding kan leiden tot verschillende visies op de doelstellingen van het oorspronkelijke
project (Mossman et al.,2010). Bij Lean PM is het dus belangrijk dat je over een goede project
manager beschikt die steeds rekening houdt met de oorspronkelijke scope van het project.
29
2.3 Agile PM
Agile PM is een concept waarbij een project wordt uitgevoerd in nauwe samenwerking met de klant.
Het team krijgt de nodige vrijheid om het project samen met de klant tot een goed einde te brengen.
De klant wordt bij elk beslissingsmoment betrokken zodat er minder kans bestaat dat er onnodig
werk wordt geleverd en een deel van het product zou moeten herwerkt worden. Dit kan een positieve
impact hebben op de projectduur en -kost. Een Agile project wordt typisch uitgevoerd door een
klein multidisciplinair team wat het mogelijk maakt dat de teamleden van elkaar kunnen leren en hun
kennisgebied kunnen verruimen.
Figuur 11: Effect van teamgrootte op het succesratio van het project
Volgens deze grafiek van ‘The Standish Group’ heeft een klein team typisch een hogere succesratio tot
gevolg. Het probleem met grote teams situeert zich hoofdzakelijk op vlak van communicatie. Volgens
Hossain, Babar & Paik (2009) treden makkelijker misverstanden, miscommunicatie en verwarring op
wanneer teams groter worden.
Wanneer gekeken wordt naar de software-ontwikkeling, is het meest voorkomende probleem dat het
verkeerde product wordt gebouwd. Dit kan gebeuren door onrealistische doelen, slecht gedefinieerde
systeemspecificaties of slechte communicatie tussen klanten, ontwikkelaars en productieondersteuning.
Deze problemen zijn nochtans heel eenvoudig op te lossen. Ten eerste moet men gerichter werken.
Doelen kunnen sterke motivatoren zijn maar het stellen van te veel doelen leidt ertoe dat mensen degene
30
kiezen waar ze een zekere affiniteit voor tonen. Te specifieke doelen leiden dan weer tot suboptimaal
gedrag en te veeleisende doelen kunnen veroorzaken dat mensen ze hoe dan ook willen bereiken en
blind worden voor de veel te hoge kosten die ermee gepaard gaan. De communicatie moet bevorderd
worden door de software ontwikkelaars direct in contact te laten komen met de klant om te weten
wat die echt wilt. Zelfs Agile maakt deze fout. De projecten worden uitgevoerd onder leiding van de
product-owner die in contact komt met de klant en beslist wat de klant allemaal nodig heeft. De meest
succesvolle projecten komen echter voor als de ontwikkelaars echt deel zijn van het businessteam en
met de klant in dialoog gaan. Een veelgemaakte fout vandaag de dag is dat bedrijven denken dat Agile
de oplossing van hun problemen zal zijn. Ze beslissen dan om te investeren in een overgang naar deze
werkwijze maar houden geen rekening met de voorwaarden die verbonden zijn aan het slagen van de
Agile aanpak. Soms is het moeilijk om Agile te implementeren in bedrijven waar de processen zich er
niet toe leiden. Niet alle bedrijfsculturen of -processen laten het werken met functionele teams of cross-
functionele teams toe. Agile werkt niet in een omgeving met sterk afhankelijke relaties tussen teams.
De teams moeten op zich sterk genoeg zijn en onafhankelijk zijn om beslissingen te nemen. Dit is een
voorbeeld van een van de basisvoorwaarden voor de implementatie van Agile projectmanagement.
2.3.1 Principes van Agile PM
Voor de beschrijving van de principes van Agile projectmanagement maken we gebruik van het Agile
Manifesto. (Beck et al, 2001)
1. Bereiken van klantentevredenheid door vroege en continue oplevering van software
Door het regelmatig opleveren van onderdelen van het product kan er feedback verkregen worden
van de klant. Daarom is het belangrijk om de klanten met de ontwikkelaars in contact te brengen.
Dit is het punt waar het schoentje nog een beetje wringt bij een Agile aanpak. Wat vandaag de
dag vooral gebeurt, is dat de ontwikkelaars communiceren met de zakenmensen die dan op hun
beurt het verhaal overbrengen naar de klant. Door deze ketting van informatie zal er meestal wel
een deeltje van de boodschap verloren gaan of verkeerd begrepen worden. Als de ontwikkelaars
direct met de klant zouden in contact komen, is de boodschap sneller overgebracht en krijgen de
ontwikkelaars ook meer voldoening van hun job door actief mee te werken aan een oplossing voor
de problemen. Een makkelijke manier om deze dialoog tot stand te brengen is door te werken
met een forum waar klant en ontwikkelaar met elkaar kunnen discussieren. De dialoog heeft tot
gevolg dat iedereen hetzelfde mentaal model heeft en er achteraf minder ondersteuning voor de
klant nodig is. Dit leidt significant tot minder kosten en defecten.
31
2. Sta open voor verandering
Zoals het woord het zelf zegt, is het bij Agile belangrijk dat het team dynamisch kan reageren op
de klantenbehoeften. Zelfs in de laatste fasen van het project kan de klant nog feedback geven. In
dit opzicht is het team totaal verschillend van een klassiek projectteam waar de scope al volledig
werd opgegeven in het begin van het project en er maar weinig feedback komt van de klant.
Daar staan het team en de project manager eerder afzijdig tegenover potentiele veranderingen.
Deze veranderingen leiden tot een change request waardoor de projectverantwoordelijke mogelijks
verantwoording moet afleggen tegenover zijn overste waarom meer resources nodig zijn om het
project te voltooien. Het is evident dat dit voor alle partijen geen aangename situatie is.
3. Lever heel frequent functionerende software op
”Do things right the first time.”Agile is er sterk op gefocust om meteen het juiste te doen. In de
software betekent dit concreet dat de code moet werken zonder defecten te genereren. Wanneer
defecten meteen gedetecteerd en opgelost worden, zijn er op het einde van het project geen
problemen meer en kan met het laatste deeltje het project zonder problemen opgeleverd worden.
Dit is slechts een deeltje van het vooropgestelde idee. Het feit dat software opgeleverd wordt,
geeft de klant de kans om ermee te werken en eventuele aanpassingen te suggereren die volgens
hem het gebruiksgemak kunnen verbeteren. Hierdoor wordt het product goed afgestemd op wat
de klant wenst. Dit is volgens ons het grote voordeel dat Agile heeft over het klassieke PM.
4. Zakenmensen en softwareontwikkelaars moeten dagelijks nauw samenwerken gedu-
rende het project
Dit is het punt waar volgens Poppendieck en Poppendieck (2009) in Agile nog problemen zouden
kunnen uit voortkomen en waar dus nog ruimte voor verbetering is. Vele fouten in productont-
wikkeling ontstaan simpelweg omdat de preferenties van de klant verkeerd begrepen worden. In
projecten is het zo dat de zakenmensen in contact staan met de klant en zo dus hun preferenties
gaan vertalen in de taal van de ontwikkelaars. Hierdoor wordt er een handover van informatie
gecreeerd. Bij handovers is het belangrijk dat de behoeften van de klant steeds worden getoetst.
Dit kan bijvoorbeeld gebeuren aan de hand van een checklist. Het is belangrijk dat wanneer er
iets fout gaat bij de handover, het falen meteen zichtbaar is. Daarom wordt er geopperd om te
werken met test-driven handovers. De vereisten van de klant zouden moeten gedefinieerd worden
met een test. Wanneer de test faalt, zal de oorzaak meteen blootgelegd worden en moet tijd
genomen worden om de fout te herstellen. Een studie bij IBM in 2003 heeft erop gewezen dat
32
deze vorm van test driven development grote voordelen geeft op vlak van de graad aan defecten
in hun IT-projecten (Maximilien & Williams, 2003).
5. Leid projecten in een gemotiveerde omgeving
Motivatie is een belangrijke drijfveer voor het slagen van projecten. Dit wordt bijna automatisch
verkregen bij het gebruik van de Agile aanpak. De teams krijgen veel verantwoordelijkheid en
de druk is er om telkens te kunnen opleveren. De teamleden worden hierdoor gestimuleerd om
actief mee te werken en voelen zich belangrijk in het proces. Er is ook geen rangorde binnen
het team, wat ervoor zorgt dat iedereen zijn inbreng kan geven en dus met een goed en voldaan
gevoel aan het werk kan. Het gevaar bestaat er echter in dat de tijdsdruk te hoog is en dat
deze de prestaties op een negatieve manier beınvloedt. Dit kan natuurlijk het geval zijn bij elke
vorm van projectmanagement. Door de snelle opleveringen, kan er wel bij elke iteratie een druk
ontstaan terwijl dit in het klassieke projectmanagement misschien minder frequent zal zijn. Dit
hangt af van het tijdsplan en de betrokkenheid van de project sponsor.
6. Face-to-face communicatie is de meest efficiente manier om informatie te delen met
en in een team
Een groot deel van de fouten in een project gebeurt zoals gezegd door misverstanden tussen
de verschillende schakels in het proces. De handovers van informatie moeten verzorgd worden.
Om toekomstige fouten te vermijden moet er dus goed gecommuniceerd worden en dit kan dan
best gedaan worden in verschillende opeenvolgende meetings waar face-to-face contact bestaat
tussen de verschillende stakeholders. Meerdere meetings inplannen heeft het voordeel dat men
kan reflecteren op basis van de voorgaande meeting en het denkproces dus wordt aangewakkerd.
7. Software die werkt is de maatstaf van voortgang
Bij de Agile aanpak wordt de voortgang typisch gemeten aan de hand van het aantal functiona-
liteiten die geımplementeerd zijn. Na elke sprint wordt er geevalueerd door de product-owner of
het product wel degelijk voldoet aan de vooropgestelde preferenties. Wanneer dit niet het geval
is, voegt hij de aanvullende correctie-acties toe aan de backlog en wordt er dan opnieuw geprio-
riteerd op basis van deze nieuwe acties. Dit sluit eigenlijk heel dicht aan bij het derde element
in dit manifesto. De sprintplanningen worden opgesteld met als deliverables de functionerende
software. Wanneer de verschillende functionerende onderdelen worden samengevoegd, kan op
een bepaald moment een Minimum viable product ontstaan dat voldoet aan de basisfunctionali-
teiten op maat van de eindgebruiker. De volledige cyclus aan sprintplanningen wordt dus telkens
33
opgesteld aan de hand van functionaliteiten die dat onderdeel van software moet bezitten. Er
wordt telkens voortgegaan op het tot dan toe geleverde product en er wordt getest wat nog nodig
is om die functionaliteiten dan toe te voegen aan de backlog. Daardoor kan gesteld worden dat
de voortgang wordt gemeten aan de hand van de software die werkt.
8. Duurzame ontwikkeling staat centraal
De teams moeten vooral bijleren. Er moet in de toekomst beroep gedaan kunnen worden op
alle informatie die beschikbaar is en die verkregen werd door ervaring in projecten van een ge-
diversifieerde aard. Een ervaren team zal de problemen en de hoofdoorzaken in de toekomst
makkelijker kunnen detecteren en aanpakken. Een ervaren Scrum-Master kan hierin een belang-
rijke rol spelen. Als hij erin slaagt om het team te focussen op bepaalde aspecten, kan hij ervoor
zorgen dat het lerende aspect tot een hoger niveau wordt getild.
9. Continue aandacht voor technische excellentie en goed design versterkt agility
Opnieuw staat het correct implementeren van de preferenties hier centraal. Verder werken op
een product dat compleet voldoet aan de preferenties spaart veel werk uit aan debuggen op het
einde en leidt dus ook niet tot onverwachte tijdsnood wanneer de oplevering van het totaalproject
zich aandient. Het belang van testen wordt hier maar weer eens benadrukt. Elke iteratie staat
voor een deeltje software dat correct moet kunnen functioneren. Van de teamleden wordt dus
verwacht dat ze dit bij elke iteratie zullen controleren.
10. Simpliciteit
Typisch wordt de lijst aan requirements, de backlog, opgedeeld in drie onderverdelingen. Dit
zijn als eerste de zaken die moeten aanwezig zijn om niet in strijd te zijn met de wet, de ’must
have’ functionaliteiten. Vervolgens zijn er de ’need to have’ functionaliteiten die nodig zijn om
het product te laten werken en als laatste zijn er nog de ’nice to have’ activiteiten die eigenlijk
niet echt nodig zijn en enkel leiden tot een product met veel toeters en bellen. Dankzij de Agile
aanpak kunnen deze laatste onderdelen kunnen worden geıdentificeerd en worden weggelaten als
er geen tijd meer is om ze te implementeren. Zo wordt het product gesimplifieerd tot wat de
klant echt nodig heeft. Het kan echter nog niet meteen duidelijk zijn wat er niet echt nodig is.
Hier komt het belang van het Minimum viable product terug. De eindgebruiker werkt met het
product en kan beslissen om sommige extra functionaliteiten weg te laten.
34
11. Zelforganiserende teams leveren de beste resultaten
De kracht van Agile ligt zoals gezegd in de capaciteiten tot samenwerken van het team. Men mag
evenwel niet blind zijn voor de beperkingen van dergelijk cross-functioneel team. Wanneer de
complexiteit echt sterk is toegenomen, kan het team mogelijk niet sterk genoeg zijn en is er vraag
naar specialisten. Een klein team kan de complexiteit niet de baas en er zullen terug handovers
zijn. Een nadeel van dergelijk team kan liggen in het ontwikkelen van een eigen dialect. Een team
zal snel een eigen dialect ontwikkelen met de teamleden waarmee ze veel gemeen hebben(Schilling,
2013). In de cross-functionele teams zijn de teamleden zo verschillend dat ze moeite kunnen
hebben om dergelijk dialect te ontwikkelen. Dit zou eventueel wel kunnen verbeteren gedurende
de voortgang van het project omdat de teamleden dan nauw in samenwerking zijn in de dagelijkse
meetings en elkaar alsmaar beter leren kennen.
12. Het team overlegt regelmatig over hoe ze meer efficient kunnen werken en proberen
hun gedrag daaraan aan te passen
Een team zit normaliter elke dag eens samen gedurende een tiental minuten waar er eens snel
wordt gepraat over de voortgang en de eventuele problemen die zich voordoen. Na elke sprint
is er dan een meer diepgaande evaluatie waar wordt ingegaan op hoe er gewerkt wordt en wat
zou verbeterd kunnen worden. Door deze sessies wordt er naar elkaar geluisterd en wordt er
nagedacht over wat er kan veranderd worden om het project makkelijker te laten verlopen. Op
die manier wordt kort op de bal gespeeld door de Scrum-master en kan dialoog worden ontwikkeld
tussen de teamleden.
2.3.2 Frameworks voor Agile PM
Er bestaan verschillende methodes voor het implementeren van Agile. Jaarlijks voert VersionOne
een onderzoek uit naar de toestand van Agile in de industrie en rapporteert deze bevindingen in hun
State of Agile Survey. In het rapport van 2015 werd een beeld geschetst van de verdeling van de
verschillende Agile methodes die gebruikt worden in de software ontwikkeling. Het resultaat hiervan
wordt in onderstaande figuur weergegeven.
35
Figuur 12: State of Agile Survey 2015: Verdeling van methodologieen in de software-ontwikkeling
Wij hebben ervoor gekozen om de Scrum-methode verder uit te diepen aangezien deze duidelijk het
meest wordt gebruikt in de industrie. Voor de beschrijving van deze aanpak baseren we ons op het werk
van Schwaber (2004). In een Scrum project worden er slechts drie rollen opgenomen. De rol van de
product-owner, het team en de Scrum-master. De product-owner moet de voorkeuren van alle personen
representeren die iets met het project te maken hebben. Dit impliceert dat hij verantwoordelijk is
voor de lijst van requirements die moet worden opgesteld bij het creeren van de backlog. Omdat
deze requirements soms moeilijk op te stellen zijn, wordt eerst een User Story opgesteld. Dit zijn
vereisten die geformuleerd zijn door de gebruikers waarbij in gewone spreektaal wordt uitgelegd wat
in het product moet aanwezig zijn. Deze user story wordt vervolgens overhandigd aan het team. Het
team krijgt de taak om voor elk van de punten op de user story de geschatte ontwikkelcapaciteit te
bepalen. De requirements die geformuleerd zijn worden opgenomen in de backlog en op basis van deze
backlog moeten de requirements worden geprioriteerd. De requirements waar de meeste waarde aan
wordt gehecht, worden eerst geımplementeerd. Het team wordt geleid door de Scrum-master. Het
is zijn taak om bij het begin van elke dag een Scrum-meeting te houden waarin elk teamlid wordt
gevraagd om een antwoord te geven op de volgende vragen:
36
� Wat heb ik gedaan?
� Wat ga ik doen?
� Wat zijn de problemen?
De Scrum-methode is een iteratieve werkwijze. Een iteratieve strategie werkt typisch vanuit een reeks
van herhaalde fasen, inclusief een feedback moment wanneer een reeks van fasen is voltooid. Dit heeft
verschillende voordelen: de klant kan telkens de oplossing voor de eisen evalueren, er kan gereageerd
worden op veranderende bedrijfsfactoren en de opzet van het project kan telkens makkelijk aangepast
worden (Fernandez, 2008). In de context van Scrum worden de korte periodes ‘sprints’ genoemd. Het
zijn periodes van typisch een tot vier weken waarin telkens een deel van het product wordt opgeleverd.
Door gebruik te maken van die iteraties, is er veel inspraak van de klant en kan deze telkens ingrijpen
wanneer er niet voldaan wordt aan de vereisten. Elke sprint wordt voorafgegaan door een meeting met
de product-owner en het team waarin wordt besproken wat tijdens de sprint moet gebeuren. Tijdens
de eerste vier uren van deze meeting wordt de geprioriteerde backlog door de product-owner voorgelegd
aan het team, waarna de teamleden onderling overleggen hoe het zal aangepakt worden. Ook zal er
discussie ontstaan tussen de leden en de product-owner over de inhoud van de backlog. Tijdens de
tweede periode van vier uren moeten de leden onderling de sprint gedetailleerd plannen. Deze planning
valt volledig onder de verantwoordelijkheid van het team. Wanneer de meeting is afgelopen, kan het
team van start gaan en wordt de sprint time-box aangevat. Elke dag komt het team samen gedurende
15 minuten en wordt de vooruitgang van het project besproken. Deze meeting wordt de daily Scrum
genoemd. Elk teamlid beantwoordt drie vragen:
� Wat heb je gedaan sinds de laatste daily Scrum?
� Wat plan je te doen tussen nu en de volgende daily Scrum?
� Welke obstakels weerhouden je ervan om jouw taken uit te voeren gedurende de sprint?
Aan het einde van de sprint wordt een sprint review gehouden. Dit is een meeting waarin aan de
product-owner en de andere stakeholders wordt voorgesteld wat werd bereikt tijdens de sprint. Op deze
manier worden alle belanghebbenden samengebracht en bekijken ze samen wat het team vervolgens zou
moeten doen. Na deze vergadering wordt onder leiding van de Scrum master een sprint retrospective
gehouden waarin hij samen met het team evalueert hoe ze te werk zijn gegaan. Dit is een belangrijk
aspect voor het team om bij te leren en deze adviezen mee te nemen naar de volgende sprint.
37
De Scrum master is een facilitator voor deze meeting. Hij zorgt ervoor dat alles in goede banen
verloopt. Volgens Derby en Larsen (2005) bestaat de jobinhoud van de Scrum master uit vijf grote
taken. Een eerste is het managen van de activiteiten. Tot deze activiteiten behoren onder andere de
brainstorming, het opstellen van de tijdlijn en de prioritisatie. Ze delen het doel om het team samen
te laten denken. Dit moet gestimuleerd worden door de Scrum master. Een andere taak is om ervoor
te zorgen dat de groepsdynamiek goed zit. In elk team zitten mensen die zich willen profileren en de
anderen gaan domineren. Dit moet door de Scrum master worden gereduceerd. Een ander element is
het managen van de tijd. Een retro meeting duurt gemiddeld drie uur. Om de verschillende activiteiten
te doorlopen en iedereen voldoende inspraak te kunnen geven, moet dit goed gecontroleerd worden.
Een vierde taak is het managen van zichzelf. Wanneer het team erg gestresseerd of gefrustreerd is, dan
heeft het nood aan iemand die daarbuiten staat en de rust kan laten terugbrengen. Hiervoor moet de
Scrum master in staat zijn om zelf de kalmte te bewaren. Als laatste is er dan nog het feit dat hij zijn
eigen vaardigheden moet blijven bijschaven. Dit kan gerealiseerd worden door ook andere meetings te
leiden dan deze retro meetings.
2.3.3 Moeilijkheden met Agile PM
Het is heel moeilijk om van een klassieke omgeving over te gaan naar een Agile omgeving. De mensen
waarmee gewerkt wordt, moeten klaar zijn om deze overgang te willen en kunnen maken. Zoals
Hofstede (2005) in zijn onderzoek al aantoonde, gaat het werken met mensen grotendeels gepaard
met verschillen in cultuur en het op elkaar kunnen afstemmen van die verschillen. Aangezien Agile
voortkomt uit Amerika, kan men stellen dat het niet op elke cultuur toepasbaar is. Hofstede maakt
gebruik van zes kenmerken om culturen met elkaar te vergelijken. Uit zijn onderzoek komt voort
dat het hier gaat om machtsafstand, individualisme, masculiniteit, vermijden van onzekerheid, korte-
of langetermijndenken en mate van toegeeflijkheid of terughoudendheid. Als we deze zaken zouden
toepassen op de principes van het Agile Manifest van de vorige paragraaf, dan kunnen we volgende
besluiten trekken met betrekking tot de verschillende kenmerken.
1. Machtsafstand
In culturen waar machtsafstand een belangrijk aandeel heeft, zullen mensen gemotiveerd worden
door hun oversten die meer macht hebben. De werknemers zullen meer vertrouwd zijn met
het krijgen van eenduidige bevelen waarin duidelijk gezegd wordt wat ze precies moeten doen.
Voor de ontwikkelaars in de Agile aanpak is het niet zo dat ze van een enkele persoon bevelen
krijgen. Zowel van de persoon voor of achter hen in de ketting kunnen er verzoeken komen. Het
38
kan vreemd zijn voor mensen die gewoon zijn om bevelen op te volgen om de overschakeling
te maken. Er kan aangenomen worden dat ze de Scrum-Master gaan zien als hun rechtstreekse
overste aangezien hij telkens de dagelijkse leiding van de meetings op zich zal nemen. Het is niet
de bedoeling dat dit gebeurt, maar dat de Scrum-master enkel zal instaan voor een goed verloop
tijdens deze meetings. Wat uitgevoerd wordt, wordt besloten door een algemene consensus te
vinden. Wanneer er nog extra zaken nodig zijn, zal dit worden toegevoegd door de product-
owner, waardoor dan weer een gezonde discussie kan ontstaan in het team. In culturen met
machtsafstand kan dit dus onwennig zijn voor de teamleden om geen rechtstreekse bevelen te
krijgen van de overste. Het veilige gevoel van controle kan hierdoor wegvallen.
2. Individualisme
In individualistische culturen kan Agile heel wat moeilijkheden ervaren. Mensen die niet gewoon
zijn om in team te werken, kunnen zich moeilijk aanpassen om dag in dag uit nauw in team
samen te werken. Deze mensen zullen vermoedelijk het meeste last ervaren met het feit dat ze
zelf niet meer in de schijnwerpers zullen staan en de roem moeten delen met de andere teamleden.
Wanneer een groot deel van de teamleden dergelijke instelling vertonen, zou dit potentieel wel
tot moeilijkheden kunnen leiden.
3. Masculiniteit
Culturen die mannelijk gedrag vertonen, zijn eerder assertief en competitief. Dit zou het werken
in team niet ten goede komen. Daarom zal het inschikkelijke aspect van het vrouwelijk gedrag
toch wel beter kunnen aansluiten bij de Agile aanpak. Het werken in team draait natuurlijk niet
alleen om het volgen van de kudde. Soms moeten belangrijke beslissingen worden genomen en
moet hiervoor in discussie gegaan worden. Discussie moet dus gestimuleerd worden tijdens de
brainstorm sessies.
4. Vermijden van onzekerheid
Ten allen tijde openstaan voor verandering staat in schril contrast met de principes van een cul-
tuur die de onzekerheid wilt vermijden. Mensen in dergelijke cultuur houden niet van verandering
en hebben eerder houvast aan patronen die constant blijven. Daarom ligt het waarschijnlijk ook
wat moeilijker om de meetings bij te wonen waar het team zichzelf constant in vraag stelt en
haar manier van werken probeert te verbeteren. Het niet hebben van een directe baas kan hier
ook de houvast wegnemen. Teamleden worden verwacht te kunnen omgaan met de gedeelde
verantwoordelijkheid in plaats van de verantwoordelijkheid die integraal bij de project manager
39
zou liggen. Een heikel punt in Agile kan dan ook zijn dat er niet rechtstreeks iemand kan worden
aangeduid die verantwoordelijk is voor het eventueel mislukken van het project.
5. Korte- of langetermijndenken
Agile is eerder gericht op het kortetermijndenken door de snelle en continue oplevering van
productonderdelen. Culturen die eerder op de lange termijn gericht zijn, zullen die tussentijdse
opleveringen niet hoog in het vaandel dragen. Dit moet met een korreltje zout worden genomen.
Ook Agile is erop gefocust om een doel op lange termijn te realiseren. Dit doel wordt opgedeeld
in korte periodes die eigenlijk kleine projecten op zich vormen. In die individuele sprints wordt
op korte termijn gekeken, maar de sprints moeten samen wel leiden tot een objectief op lange
termijn. Het feit dat bij klassiek projectmanagement de projecten niet worden opgedeeld in
zoveel individuele delen maar waar wel mijlpalen worden opgesteld, wordt ook geprobeerd om
van dat langetermijndenken af te stappen. Een project dat te eng gedefinieerd is op lange
termijn, is te moeilijk om onder controle te houden en bijgevolg de focus te kunnen behouden.
6. Toegeeflijkheid vs terughoudendheid
In strikte omgevingen die gepaard gaan met een uitgesproken vorm van terughoudendheid en
met een groot aantal sociale normen waar alles al van op voorhand moet vastliggen en niet van
het plan mag afgeweken worden, zal het extreem moeilijk zijn om Agile te implementeren. De
principes van het Agile manifesto met betrekking tot de simpliciteit en het openstaan voor ver-
andering zullen in dergelijke omgeving geen steek houden. Alles moet geımplementeerd worden
zoals op voorhand vastgelegd zonder hiervan af te wijken. Ook het element dat de maatstaf voor
vooruitgang beschrijft zal verschillend zijn in deze omgeving. In Agile wordt, zoals gesteld, de
vooruitgang gemeten aan het feit dat de software werkt of niet. In een terughoudende omgeving
worden aanvaardbaarheidslimieten opgesteld waaraan het eindproduct moet voldoen. Agile zal
beter werken in een omgeving die toegeeflijk is en waar het team zelf de beslissingen kan nemen.
Livari en Livari (2011) voerden onderzoek naar een cultuur die er zich het best toe leende om de Agile
methode op toe te passen. Ze baseerden zich op eerder onderzoek van Quinn en Rohrbaugh (1983)
waar het Competing Values Model (CVM) werd opgesteld. Dit model maakte een onderscheid tussen
structuur en focus. Op vlak van structuur werden verandering en stabiliteit voorgesteld als elkaars
tegengestelden. De verandering staat voor flexibiliteit en spontaniteit, terwijl stabiliteit meer focust
op controle en continuıteit. De focus werd onderverdeeld in een interne en een externe focus. Interne
focus betreft de integratie en het onderhoud van het interne socio-technische systeem. Externe focus
40
draait om competitie en interactie met de omgeving. Deze tegenstellingen creeerden vier kwadranten
die elk een bepaalde cultuur representeerden.
Figuur 13: Competing Values Model (Quinn)
Een eerste cultuur is de groep cultuur. Deze cultuur vergt minder controle en heeft een interne focus.
Dit is in tegenstelling tot een rationele cultuur, waar de stabiliteit en controle belangrijk zijn met de
focus op de externe omgeving. De hierarchische cultuur is dan weer gekenmerkt door stabiliteit en
interne focus. Hier draait het om zekerheid en het ontwikkelen van een zekere routine in de processen.
Als laatste is er dan nog de ontwikkelingscultuur. Deze focust op de toekomst en staat voor flexibiliteit.
Livari et al.(2011) stellen dat Agile het best in deze cultuur kan worden geımplementeerd aangezien
de flexibiliteit en het adaptieve karakter zeer belangrijk zijn. Ook worden de requirements frequent
veranderd en zijn deze veranderingen afhankelijk van de omgeving, waardoor de externe focus hier
ook belangrijk is. Het mag duidelijk zijn dat niet elke cultuur geschikt is om de Agile aanpak te
implementeren.
Cobb (2011) stelt dat de overgang van een klassieke omgeving naar een Agile omgeving met veel geduld
moet gepaard gaan. In een omgeving waar onvoldoende sponsoring en langetermijntoewijding van het
management aanwezig zijn, is de overgang naar Agile gedoemd om te mislukken. In de beginfase zal
niet alles vlot verlopen en zal het team fouten maken. Onafgewerkte producten, fouten en andere
obstakels zullen in iedere iteratie voorkomen gedurende de opstart. Wanneer er dan niet genoeg steun
aanwezig is, zal de transformatie naar Agile vroegtijdig onderbroken worden en zal teruggegaan worden
41
naar de initiele aanpak, wat in hun ogen de makkelijkste oplossing is. De moeilijkheid betreffende de
implementatie van Agile bestaat erin dat er geen specifieke methodologie voorhanden is over hoe je
de aanpak moet implementeren. De principes worden voorgeschoteld en het is dan aan de persoon die
ervoor verantwoordelijk is om deze principes te interpreteren en toe te passen op de projectomgeving.
Hier kunnen dus makkelijk verkeerde interpretaties ontstaan. Zo kan het bijvoorbeeld zijn dat de
principes in extreme vorm werden toegepast zoals bijvoorbeeld de afwezigheid van documentatie, het
niet consistent zijn van de controle van de verandering met Agile. Deze worden niet uitgesloten in
de Agile aanpak maar het is aan de gebruiker om ze af te stemmen op de omgeving van het project.
Hierdoor werd Agile foutief geınterpreteerd door sommige project managers en werd een beeld geschetst
van een aanpak die in hun ogen voorschrijft dat de initiele waarden van de waterfall aanpak zomaar
in plan worden gelaten.
Naast moeilijkheden met de cultuur kan ook gekeken worden naar moeilijkheden die de werknemers
ervaren. Zo is er met Agile de potentiele afwezigheid van het gemeenschappelijke dialect tussen de leden
van het team. De teamleden zijn zo verschillend dat ze het moeilijk hebben om vlot te communiceren
met hun collega’s. Zoals in de paragraaf met de principes van Agile al werd uitgelegd, is dit vooral het
geval in het begin van het project. Wanneer de leden elkaar beter leren kennen, ontstaat er snel een
nieuw dialect. Verder kan het ook moeilijk zijn om mensen effectief toe te wijzen aan een team. Het
zogenaamd werken met gedeelde resources, zoals in vele projecten het geval is, kan hier onmogelijk
worden toegepast. Iedereen moet voltijds meewerken en beschikbaar zijn voor het project. Ook een
time to market en budgetten die vastgelegd zijn per periode, bemoeilijken het gebruik van Agile. In de
Project Triangle van het klassieke projectmanagement, werd getoond dat deze aanpak gedreven wordt
door een duidelijke planning. Agile daarentegen in een waardegedreven aanpak waar wordt gekeken
wat kan bereikt worden met een gegeven tijd en budget.
Als laatste is de schaal waarop een methodologie als Scrum of Extreme programming kan werken een
moeilijkheid. In een klein bedrijf kan je perfect te werk gaan met dergelijke methodologie omdat de
cultuur minder verdeeld is in lagen. Het management is heel kort betrokken bij alles wat gebeurt op
vlak van projecten. Wanneer er echter gekeken wordt om bijvoorbeeld Scrum toe te passen in een
groot bedrijf dat werkt op wereldschaal, komt men al snel tot de conclusie dat deze frameworks hier
niet klaar voor zijn. Daarvoor zijn er echter andere methodes ontwikkeld zoals SAFe4, LeSS5 en DaD6
die wel gericht zijn op het op grote schaal uitvoeren van een Agile methodologie.
4Scaled Agile Framework, ontwikkeld door Dean Leffingwell in 2011 - www.scaledagileframework.com5Large Scale Scrum, ontwikkeld door Larman en Vodde in 2005 - https://less.works/6Disciplined agile Delivery, ontwikkeld bij IBM door Ambler en Lines in 2012 - www.disciplinedagiledelivery.com
42
Een voorbeeld van SAFe wordt gegeven in de sectie Bevindingen uit de praktijk met de projectaanpak
van ING Belgie.
2.3.4 Interpretaties rond Agile PM
Cobb (2011) beschrijft in zijn boek dat nogal wat misconcepties rond Agile aan de basis liggen van
de kritiek die heden ten dage ontstaan is rond Agile. De polemiek komt vooral uit de hoek van
de aanhangers van het traditionele projectmanagement en de PMBOK. Dit hebben wij zelf kunnen
ondervinden na een gesprek met Chris F. Kindermans. Kindermans heeft 30 jaar ervaring als project
manager en is actief op vlak van coaching en implementatie van de klassieke projectmanagement
aanpak. Zijn opinie omtrent Agile is dat het wordt gezien als een oplossing om beide partijen, software-
ontwikkelaar en opdrachtgever tevreden te stellen. De software-ontwikkelaar doet graag zijn eigen
ding en vergeet nogal dikwijls het kosten-en tijdsplaatje en houdt dus van voldoende vrijheid. De
opdrachtgever heeft niet graag dat de project manager om change requests vraagt want hij houdt er
niet van om dan aan het hoger management extra tijd en budget te vragen om de change request in
te willigen. Met Agile zijn er geen uitgesproken change requests omdat de scope bij elke sprint wordt
herzien.
Een eerste misconceptie is volgens Cobb dat Agile wordt gezien als niets meer dan een stel program-
meurs die samenzitten en op een ongestructureerde manier code beginnen te schrijven. Deze mening
wordt ook door Kindermans gedeeld. Agile is echter een planning gestuurde methode en is heel sterk
gedisciplineerd rond het uitvoeren van het werk. De arbeid die de programmeurs uitvoeren wordt
gecontroleerd door allerhande tools. Natuurlijk wordt van het team een zekere zelfdiscipline verwacht,
wat zoals eerder gesteld een van de moeilijkheden kan zijn die met Agile gepaard kunnen gaan.
Een tweede aspect is het feit dat sommige mensen in de Agile beweging de frameworks als Scrum en
XP7 gaan promoten zodat het lijkt dat er geen andere methode bestaat dan deze en dat ze strikt moeten
opgevolgd worden. Dit is volgens Cobb verkeerd begrepen aangezien de Agile methodologieen kunnen
worden aangepast aan de projecten. In tegenstelling tot een pure Agile aanpak kan het gecombineerd
worden met andere vormen van projectmanagement, waaronder ook het klassiek projectmanagement.
Dit kan het geval zijn wanneer een evenwicht moet worden gevonden tussen controle en agility. Niet
elke cultuur leent zich immers toe aan het verlenen van de volledige vrijheid aan het projectteam.
Sommigen denken dat Agile de traditionele vorm van projectmanagement wenst vervangen. Ze stellen
7Extreme Programming, een methodologie voor software-ontwikkeling, ontstaan bij Chrysler door Beck in 1999 -
www.extremeprogramming.org
43
dat de tools en toepassingen van het klassieke projectmanagement irrelevant gaan worden. Dit kan
onmogelijk het geval zijn aangezien Agile niet voor elk project kan toegepast worden. De klassieke
principes kennen zeker nog hun waarde en kunnen worden versterkt wanneer een combinatie tussen
beide kan worden ontwikkeld.
Een mening die Kindermans ook deelde is degene die stelt dat Agile louter een ontwikkelingsmethodo-
logie is en geen vorm van projectmanagement of framework. Dit is vermoedelijk veroorzaakt door de
toepassing van Agile in haar beginstadium. Toen was de methode weinig gestructureerd. Tot op de
dag van vandaag is Agile enorm geevolueerd en is Scrum een methodologie geworden die zich baseert
op een goed gefundeerde basis aan kennis. Ook het feit dat Agile gebruik maakt van een omgekeerde
project triangle stelde Kindermans ter discussie. Een aanpak die uitgaat van een gegeven budget en
een gegeven tijdsdoel maar de scope volledig variabel laat, is volgens hem geen vorm van projectma-
nagement. Het team beslist dan zelf wat ze maken en indien dit niet overeenkomt met wat de klant of
sponsor voor ogen heeft, is er alsnog een change request nodig en is men weer bij af. Dit kan inderdaad
een risico zijn dat met Agile genomen wordt. Cobb stelde zoals eerder aangegeven dat Agile deze fout
vooral maakte in haar beginjaren maar dat ze nu aan maturiteit gewonnen heeft.
De redenen waarom deze misconcepties ontstaan, is omdat Agile in se niet prescriptief is. Het zegt
je niet specifiek wat je moet doen. Er is nog een zekere interpretatie nodig door de leidinggevende
persoon. Hierdoor lijkt het van buitenaf alsof het team een vrijgeleide zou krijgen om uit te voeren
waar het zin in heeft.
2.4 Klassiek PM vs Lean PM
Wanneer projecten worden gepland met als doel het maximaliseren van de waarde en ondertussen
ook het minimaliseren van verspillingen, dan worden deze vaak Lean projecten genoemd. Om een
beeld te schetsen over de gelijkenissen en verschillen tussen beide methodologieen, zullen we de figuur
van het Lean framework LPDS analyseren. Het project start met de Definitie waarin de scope wordt
geschetst. In de Design fase wordt deze scope gedetailleerder uitgewerkt om vervolgens in de Supply
over te gaan tot een detailplanning. In de Assembly wordt het project uitgevoerd en in de Completion
wordt het afgesloten. De controle gebeurt doorheen het volledige project. Deze fasen komen ongeveer
overeen met de fasen die beschreven werden in de klassieke levenscyclus, maar het verschil tussen het
traditionele PM en Lean PM is groter dan op het eerste zicht merkbaar is. Een eerste verschil treedt op
tijdens de ontwerpfase van het project. Lean PM stelt beslissingen uit tot op het laatste ogenblik zodat
er meer tijd is voor het ontdekken en ontwikkelen van nieuwe alternatieven. Medewerkers onderaan
44
de ladder worden betrokken bij beslissingen die van bovenaf gemaakt worden. In het traditionele
PM bekijkt men de beschikbare opties en maakt men zo snel mogelijk een werkschema op met de
verschillende taken. Deze aanpak heeft als nadeel dat het ontwerp vaak moet worden geherformuleerd
doordat een beslissing van de ene specialist een conflict veroorzaakt met een beslissing van een andere.
Lean PM zorgt ervoor dat het continue leerproces is opgenomen in projecten, de filosofie van het
bedrijf en hun supply-chain management. Na ieder project volgt er een ‘learning loop’ waarbij de
verschillende teams veel leren uit de fouten die zijn opgetreden. Bij de traditionele aanpak treedt dit
leereffect eerder sporadisch op (Ballard et al., 2003).
Een derde verschil is dat Lean PM regelmatig inspanningen doet om de doorlooptijden te verminderen
en de belangen van de stakeholders op te nemen. In het traditionele PM gebeuren deze inspanningen
niet en is iedere organisatie afzonderlijk verbonden met de markt, waardoor ze niet kunnen genieten
van deze voordelen (Ballard et al., 2003). Lean Project Delivery System toont expliciet de relaties en
afhankelijkheden tussen de verschillende fasen door middel van hun overlappende activiteiten. Dit is
iets wat bij klassiek projectmanagement vaak wordt genegeerd.
Wanneer we dan kijken naar de gelijkenissen, kunnen we zien dat verschillende van de zes Lean
principes, er een aantal zijn die worden teruggevonden in de PMBOK. Een eerste is het principe van
de kwaliteitscontrole. In Lean PM wordt dit wel nog anders aangepakt door nog vroeger te gaan
testen. Een andere gelijkenis is het respect en de integriteit die in Lean centraal staat. Deze zaken
worden teruggevonden in de code of ethics van de PMBOK.8 Het principe rond het zo laat mogelijk
plannen van activiteiten, komt overeen met de Critical Chain methode die in de sectie omtrent het
klassieke projectmanagement werd behandeld. Deze aanpak is er ook op gericht om de activiteiten
zo laat mogelijk te plannen en dit wordt dus ook erkend in de PMBOK als een van de methodes
om te plannen, rekening houdend met de resources die moeten toegewezen worden. Critical Chain
is ook een projectmanagement methode op zich.9 Ze is ontstaan uit het feit dat in het klassieke
projectmanagement de activiteiten een safety time bevatten. Volgens Shen en Chua (2008) is deze
methode veel agressiever dan Lean projectmanagement. De eerste stap bestaat er immers in om de
duur van de activiteiten te halveren om zo de safety time te elimineren. Het risico dat daarmee
ontstaat, kan dan later terug opgevangen worden in de buffers. In Lean projectmanagement probeert
men ook om de safety time die in de activiteiten aanwezig is, en in het klassieke projectmanagement
ook blijft, weg te werken. Door deze weg te werken, wilt men met Lean bereiken dat het accurater zal
8Project Management Institute, PMI Code of Ethics and Professional Conduct. - www.pmi.org/codeofethicsPDF9Critical Chain Project Management (Goldratt)
45
worden om de activiteiten te plannen. Shen et al.(2008) wijzen hiermee dus op de betrouwbaarheid die
Lean aan het project kan bieden met haar aanpak. In een omgeving die stabiel is, kan dit inderdaad
goed werken, maar dit is zeker niet overal zo.
2.5 Klassieke PM vs Agile PM
Zoals uitvoerig beschreven in bovenstaande paragrafen, werkt het traditionele PM volgens een lineaire
strategie die bestaat uit opeenvolgende, afhankelijke fasen die worden uitgevoerd zonder feedback
loops. De oplossing wordt enkel op het einde van het project aan de klant voorgesteld (Fernandez,
2008). Het grote probleem bestaat erin dat telkens het product of de oplossing niet voldoet aan de
vereisten van de klant, geformuleerd in de scope, een groot deel van het product moet worden aangepast
en de projectduur en -kost hoog kunnen oplopen. Het voordeel is echter dat het project van bij de start
gepland is en men dus al weet welke middelen nodig zijn in de loop ervan. Hier wordt er gefocust op
de risicoreductie en het onder controle houden van tijd en kost. Men focust in de eerste fasen meteen
op scope, tijd en kost. De klant maakt duidelijk, in de mate van het mogelijke, wat hij verwacht van
het eindproduct. Vervolgens wordt op basis daarvan een initiele planning opgemaakt en wordt verder
gekeken hoeveel budget nodig zal zijn voor het project. Dit totaalplaatje wordt gedocumenteerd en
voorgelegd aan het management. Wanneer er echter veranderingen nodig zijn gedurende het project
is er telkens een change request nodig en bestaat de kans dat er extra budget en tijd moet gevraagd
worden aan het management. Dit werd al eerder duidelijk gemaakt in de Project Triangle. Initieel ligt
de scope vast terwijl tijd en budget daarop worden afgestemd. Gedurende het project kan nog worden
afgeweken van het initiele plan. Op basis van deze driehoek kan al een eerste onderscheid worden
gemaakt tussen het klassieke projectmanagement en de Agile aanpak. Dit werd door Dean Leffingwell
(2010) beschreven in volgende figuur.
46
Figuur 14: Verschil tussen het Traditioneel PM en Agile PM mbt Scope Triangle
Bij traditioneel projectmanagement wordt de scope in het begin van het project vastgelegd terwijl
budget en tijd daarvan afhankelijk zijn. Het budget en de tijd worden afgestemd op wat nog moet
uitgevoerd worden van de totale scope. Agile daarentegen vertrekt van een backlog aan requirements
op basis waarvan men dan telkens prioritiseert. Binnen een gegeven termijn en een budget wordt een
zo groot mogelijk deel van de backlog uitgevoerd. Het gevaar bestaat erin dat de klant uiteindelijk
wordt opgezadeld met een product dat hij eigenlijk niet nodig heeft. Wanneer men op het einde
van de termijn het project oplevert en bepaalde zaken niet aanwezig zijn in het project, omdat ze
niet toegewezen werden in de backlog, moet er mogelijk meer tijd en meer geld gevraagd worden, wat
opnieuw resulteert in een moeilijke situatie voor de projectverantwoordelijke. Daarom moet dit project
strikt geleid worden door een project manager die nauw verbonden is met het gewenste eindproduct
dat dient verkregen te worden. In tegenstelling tot klassiek projectmanagement werkt Agile PM met
kleine multidisciplinaire teams die voortdurend met elkaar overleggen en elkaar aanvullen. De klant
heeft ook nog voldoende inspraak in het proces en kan ingrijpen op tijdstippen waar er nog makkelijk
kan aangepast worden zonder het project volledig te moeten bijsturen en dus onnodige kosten te
maken. Hier wordt niet gefocust op tijd en kost maar wel op wat er aan de klant geleverd wordt en
wat de waarde hiervan is. Daarom ook dat in de figuur werd beschreven dat Agile een waardegedreven
methode is.
Hass (2008) is erin geslaagd om de beide methodes te vergelijken op basis van verschillende basisele-
menten. Een eerste is de visuele controle. Teams die gebruik maken van Agile zorgen ervoor dat het
project visueel heel duidelijk is. Dit kunnen ze doen door middel van de ‘cards-on-the-wall’ methode
47
waarbij de taken en eisen van de klant met betrekking tot het project worden voorgesteld door middel
van post-its op een muur of bord. Een tweede element is de locatie van de teams. In het traditionele
PM werken de teamleden minder afhankelijk van elkaar, wordt er slechts zelden geınterageerd met
de eindgebruiker en draagt de project manager de eindverantwoordelijkheid. In de context van Agile
werken alle teamleden in een ruimte en overleggen met elkaar wanneer er iets niet duidelijk is. Uit
vorige paragraaf blijkt dat een project manager de duidelijke eindverantwoordelijkheid zou moeten
dragen betreffende de vereisten van het product. Verder is ook de manier van controle verschillend.
Telkens een deel van het product, uitgedrukt in function points, is afgewerkt, dient dit gecontroleerd
te worden. Bij de klassieke projectmanagement aanpak in de PMBOK, hebben we gezien dat er per
fase een controle en kwaliteitstest gebeurt. Dit is minder specifiek gericht op de functionaliteiten van
het product dan bij Agile. Dit zorgt ervoor dat er bij de Agile aanpak sneller een Minimum Viable
Product zal zijn waarmee al gewerkt kan worden en de ervaringen zullen aantonen wat er nog kan
veranderd worden aan het product. Ook de lerende aspect van het team is belangrijk. In een tra-
ditionele context is de projectleider aangesteld om het team doorheen het project te begeleiden en
de voortgang op te volgen. In de Agile aanpak leren de teamleden bij van fouten in de vorige fase.
Ze kunnen deze informatie dan meenemen in het verdere verloop van het project. Het is dan wel
noodzakelijk dat iemand hen op hun fouten wijst en toont hoe ze dit beter aanpakken in de toekomst.
Dit kan de taak zijn van de andere teamleden onder vorm van sociale controle maar het lijkt beter
om dit te laten doen door een projectverantwoordelijke met een bredere kijk op het project. Een
vijfde element is de samenwerking in de ontwikkeling van een product door de teamleden in het Agile
PM. De projectleider beslist over de initiele planning en stelt prioriteiten in de opeenvolging van de
ontwikkeling van de eisen. Dit houdt meteen een volgend element in. De meest risicovolle activiteiten
en belangrijkste functionaliteiten in de backlog worden eerst geımplementeerd en vervolgens worden
de andere activiteiten gepland op basis van het waardecreerend vermogen van de activiteit voor het
bedrijf. Een laatste punt is de evolutie van het louter dirigeren en controleren naar leiderschap en
samenwerking. Agile PM staat veel dichter bij leiderschap en samenwerking dan het traditionele PM.
Het is dan ook duidelijk dat in een Agile-methode meer toewijding en inzet wordt verwacht van de
teamleden (Fernandez, 2008). Deze toewijding is op twee vlakken. Enerzijds wordt bedoeld dat
iedereen voltijds beschikbaar moet zijn en anderzijds moet de inzet groot zijn omdat er veelvuldig
moet gecommuniceerd en afgestemd worden met het team en de klant. Dit kan een nadeel zijn
aangezien er op zoek moet gegaan worden naar goeie krachten die uitmuntende competenties bezitten
in het werken in groep en communiceren van eventuele problemen. Ook de cultuur moet als dusdanig
48
aangepast worden naar een snel reagerende en communicerende omgeving. Alleen op die manier kan
er geevolueerd worden naar een cultuur die zowel reactief en proactief te werk gaat (Owen & Koskela,
2006). In de PMBOK hebben we gezien dat mensen worden gemotiveerd door projecten waarin ze
worden uitgedaagd. Het is duidelijk dat dit wordt versterkt in een Agile project. Het feit dat er meer
wordt verwacht van het team, zorgt ervoor dat ze gemiddeld meer geengageerd zullen zijn om zich in
te zetten met als doel het project op tijd en binnen budget af te leveren.
In de praktijk zien we dat sommige bedrijven er moeite mee hebben om het team de volledige vrijheid
te laten die nodig is voor Agile. Het management wilt duidelijk weten bij aanvang wat het totale
project nodig heeft qua tijd en budget. Dit kan alleen maar als alles duidelijk gepland is van in het
begin. Daarom is er vraag naar een methodiek die werkt via iteraties en continue oplevering van delen
van het product maar waar de activiteiten toch al grotendeels worden gepland. Deze bedrijven starten
dan met de activiteiten gedetailleerd op te stellen en te verdelen per sprint. Op die manier kan nog
steeds volgens iteraties te werk gegaan worden maar is er toch een groter gevoel van controle bij het
management. Hoewel Scrum-methode, die eerder werd voorgesteld, heel populair is, kent ze nog vrij
veel gebreken in de praktijk.
2.6 Lean PM vs Agile PM
Volgens verschillende bronnen in de literatuur wordt weinig onderscheid gemaakt tussen Lean en Agile.
Wang, Conboy & Cawley (2011) daarentegen beschrijven verschillende punten waarop Lean en Agile
zich wel degelijk onderscheiden ten opzichte van elkaar. Een eerste verschilpunt is het doelpubliek.
Agile is er vooral op gericht om ontwikkelaars bij te staan en is dan ook ontwikkeld vanuit het ope-
rationele perspectief. Lean daarentegen is een methodologie die vanuit een management perspectief
wordt geımplementeerd. Lean is dus een top-down aanpak. Hierin is vooral de optimalisatie van de
activiteiten belangrijk.
Zoals eerder werd beschreven volgt Lean een sequentieel verloop. Denyer et al. (2011) wezen er ook op
dat door gebruik te maken van Lean de flexibiliteit wordt beperkt. Dit omwille van de minimalisatie
van de slack time. Agile daarentegen is heel flexibel en geeft ten allen tijde de mogelijkheid om
aanpassingen te suggereren.
Een derde verschil is de toepasbaarheid van de beide methodes. Agile wordt vooral toegepast binnen
de software ontwikkeling en het projectmanagement terwijl Lean een brede waaier aan toepassingen
heeft. Dit kan evenwel in de software-ontwikkeling zijn maar ook op bedrijfsniveau waar de software-
ontwikkeling maar een klein deeltje van is.
49
Poppendieck & Poppendieck (2003) focussen op de specifieke toepassing van Lean binnen de software-
ontwikkeling. Volgens hen verbreedt Lean development de theorie van Agile door de algemeen bekende
principes van Lean toe te passen binnen de software-ontwikkeling. Dit wijst erop dat Lean actief is in
verschillende sectoren. Het specifieke Lean PM in de software ontwikkeling wordt dikwijls beschouwd
als een vorm van Agile.
Verschillende auteurs wijzen er ook nog op dat Agile vooral op kleine schaal kan worden gebruikt. Lean
daarentegen kan er volgens Ambler (2009) voor zorgen dat problemen in grotere teams kunnen worden
opgelost. Dit kan door middel van het afstemmen van de teamstructuur met de bedrijfsarchitectuur,
risico gebaseerde mijlpalen en gefaseerde oplevering van projecten. Er kan dus gewezen worden op de
invoering van Lean Governance toepassingen die ervoor zorgen dat wanneer schaalvergroting wordt
toegepast, er geen problemen kunnen opduiken. Frameworks als SAFe, LeSS en DaD doen hier terug
hun intrede. Zoals zal geıllustreerd worden in de case van ING, is het voor grote bedrijven met
verschillende lagen heel belangrijk om de voeling met de strategie niet te verliezen. In deze context
kunnen laatstgenoemde frameworks heel waardevol zijn. Deze bedrijven willen niet inboeten op vlak
van vrijheid van de teams maar proberen ze wel te sturen in een bepaalde richting. Dit is het verschil
met de aanpak die wordt voorgesteld om een combinatie te maken tussen waterfall en Agile in de vorige
paragraaf. Daar wordt de vrijheid van het team wel verminderd door op voorhand vast te leggen wat
moet uitgevoerd worden in welke sprint. Het is wel duidelijk dat veel bedrijven zich vandaag de dag niet
meer willen beperken tot een aanpak maar ervoor opteren om verschillende methodes te combineren
in een framework. Afhankelijk van de bedrijfscultuur wordt dan een keuze gemaakt.
50
3 Bevindingen uit de praktijk
3.1 IT-Projecten
3.1.1 The Standish Group: Chaos Report
Sinds 1994 publiceert The Standisch Group, een internationaal adviesorgaan voor projectmanagement
in de IT-sector, jaarlijks het zogenaamde Chaos Report. Het is een soort van snapshot van de toe-
stand van de software industrie. Onderstaande figuur toont de distributie van projecten over succes,
uitdagend en falen voor de laatste vijf jaar, geschat door The Standish Group.
Figuur 15: Chaos Report 2015: Evolutie van distributie ivm het slagen van projecten
De evolutie in de uitkomst van projecten blijft nagenoeg constant over de laatste vijf jaar. Ongeveer
een op vijf projecten die werden geobserveerd in de software-ontwikkeling faalde. Hier werd geen
onderscheid gemaakt in de aanpak die werd gehanteerd. In volgende figuur is dit wel het geval. Zowel
voor de klassieke waterfallmethode als de projecten die met behulp van Agile werden uitgevoerd, wordt
geschat wat de resultaten van de projecten zijn. Deze figuur toont aan dat Agile over het algemeen
betere resultaten geeft dan de waterfallmethode. De klassieke methode heeft het moeilijker om de
vereisten van de klant goed in kaart te brengen in het begin. Agile past deze vereisten aan gedurende
het project en laat de klant werken met een Minimum viable product zoals ook in de casestudie van
Bru Textiles in de volgende sectie te zien is.
51
Figuur 16: Vergelijking van projectresultaten tussen Waterfall en Agile
In 2013 publiceerde The Standish Group het Chaos Manifesto. Hierin werd onder andere aangegeven
welke factoren een belangrijk aandeel hebben in het succes van kleine projecten. Een eerste succesfac-
tor is ondersteuning van het uitvoerend management. Hiermee wordt gedoeld op de project sponsor.
Het project staat of valt met deze persoon. Voor een klein project is het niet nodig dat de sponsor
een hoge functie in het bedrijf uitoefent. Deze moeten gespaard worden voor de grote projecten. Voor
deze kleine projecten is een manager die de vaardigheden bezit en geengageerd is belangrijker. Onder-
handelingen moeten hier ook tot een minimum beperkt worden. Het project dient op tijd te worden
afgewerkt en zo weinig mogelijk tijd en geld moeten verspild worden aan onderhandelen en andere
activiteiten die slechts beperkte waarde toevoegen. Een tweede factor is het betrekken van de gebrui-
ker. Projecten waar de gebruiker gevraagd wordt naar zijn ervaringen en mening, leiden algemeen tot
betere resultaten dan wanneer dit niet gebeurt. Het team en de gebruiker moeten goed samenwerken
zodat de vereisten van de gebruiker duidelijk zijn voor het team. Ook optimalisatie is een belangrijke
factor voor kleine projecten. Vooral wanneer een project binnen een korte termijn klaar moet zijn, is
dit een uiterst belangrijke factor. Kleine projecten zijn vaak risicovol aangezien het meestal gaat om
een nieuwe en onbekende technologie. Gezien dit risico dient het project geoptimaliseerd te worden.
Verder zijn ook de vaardigheden van de projectmedewerkers belangrijk. Hier komt het HR-aspect weer
bovendrijven. De project manager dient goed om te springen met de vaardigheden die beschikbaar
zijn voor het project. Succes of falen is voor een groot deel afhankelijk van de mensen die aan het
project werken. Diversiteit is hier een belangrijk aspect. Ook de ervaring in projectmanagement wordt
52
opgenomen in de succesfactoren. De project manager moet zich baseren op zijn expertise om bepaalde
situaties in te schatten en beslissingen te nemen die als moeilijk ervaren worden. The Standish Group
neemt voor het eerst ook Agile processen op in de top tien. Dit omdat Agile rechtstreeks doelt op
betrokkenheid van de gebruiker, management ondersteuning en andere factoren. Vooral kleine projec-
ten of projecten die in kleinere delen kunnen worden opgesplitst, vormen een goed toepassingsgebied
voor een Agile aanpak. De volgende vier factoren zijn in mindere mate belangrijk. Als eerste is er
een duidelijk zicht op de bedrijfsdoelstellingen. Voor grotere projecten is dit wel een belangrijk aspect
aangezien deze moeten passen in de strategie van het bedrijf op korte en lange termijn. Bij het kleine
project zal de doelstelling dikwijls minder duidelijk zijn. Aangezien alle projecten toch binnen de
filosofie en strategie moeten gebeuren, wordt er toch meer aandacht aan gehecht dan aan de volgende
drie factoren. Emotionele maturiteit betreft de emotionele toestand van de projectomgeving. Een
gezond ecosysteem produceert meer succesvolle projecten. Wanneer de onderlinge relaties tussen de
stakeholders niet goed zijn, kan dit dodelijk zijn voor een project. De communicatie is cruciaal in
het identificeren en tegemoetkomen van en aan de vereisten van de gebruiker. Ook het proces van
besturen en controleren van het project wordt opgenomen in de factoren. Dit focust hoofdzakelijk op
de financiele controle en procedures. Ook bij een klein project moeten er vereisten gesteld worden
en moet de performantie van het team bijgehouden worden. Zoals eerder gezegd is het stellen van
doelen een gevaarlijk punt. Te hoge doelen kunnen leiden tot frustraties en te lage doelen leiden tot
verspilling van tijd en geld. Een laatste factor is de infrastructuur en de tools die voorhanden zijn.
Met het aantal gehanteerde tools moet voorzichtig worden omgesprongen want elke gebruikte tool kan
de werking van het project grondig verstoren.
Met dit manifest wijst The Standish Group op de voordelen om kleine projecten te voeren of om
een groot project op te delen in verschillende kleine. Dit laatste is echter een moeilijke taak. Kleine
projecten liggen nogal gevoelig bij leidinggevenden. Sponsors verkrijgen een zekere status wanneer ze
betrokken zijn bij een groot project. Een tweede element is dat overhead kosten typisch groot zijn
in vergelijking met de waardecreatie van het project. Vele bedrijven combineren daardoor meerdere
kleinere projecten in een groot project maar daarbij wordt soms de fout gemaakt dat niet alle kleine
projecten in dezelfde richting georienteerd zijn. Op deze manier neemt de complexiteit sterk toe. Het
advies van The Standisch Group is duidelijk: probeer om grote projecten te verdelen in meerdere
kleine projecten, met het oog op de objectieven. Dit is duidelijk een pleidooi voor de Agile methodiek.
53
3.1.2 Bru Textiles
Bru Textiles is een wereldwijde leverancier van interieurbekleding gevestigd in Kontich. Bru Texti-
les maakt sinds een jaar gebruik van Agile PM voor het managen van hun IT-projecten. Voor de
implementatie van Agile werd gebruik gemaakt van het Scrum framework omwille van de volgende
aanvaarde waarheden:
� Het is onmogelijk om alle vereisten vooraf te bepalen.
� De vereisten veranderen tijdens het project.
� Er zal altijd meer werk zijn dan tijd en geld toelaten.
In 2014 werd het voor de eerste maal gebruikt bij het ontwerp van een ERP-systeem voor de aansturing
van hun geautomatiseerd magazijn. We hebben het verloop van dit project samen met Dieter Verlaeckt,
IT-director bij Bru, doorlopen. De duur van dit project werd op voorhand geschat op een jaar.
3.1.2.1 Projectbeschrijving
Omwille van een sterke groei en extra nood aan opslagcapaciteit besloot Bru Textiles een geautomati-
seerd warehouse te bouwen. De picking van de textielrollen werd gestuurd door een ERP-systeem, dat
geımplementeerd werd door gebruik te maken van Agile PM. Eerst werd in Excel een release planning
opgemaakt waarbij alle fasen van het project worden voorgesteld. Elke fase beslaat meerdere cellen
en elke cel bestaat uit een optimaal aantal van vier of vijf user stories, een lijst met eisen waaraan
het product moet voldoen volgens de stakeholders. De product-owner bepaalt voor elke user story de
acceptance criteria waaraan voldaan moet worden. Op deze manier wordt een range bepaald waarbin-
nen het product moet kunnen gebruikt worden. Hierdoor wordt een zekere controle ingebouwd, wat
zeker nodig is wanneer gebruik wordt gemaakt van Agile.
54
Figuur 17: Projectplanning: Geautomatiseerd magazijn Bru Textiles
De requirements werden opgedeeld in drie categorieen. Eerst zijn er de ’Must haves’. Deze zaken
moeten zeker aanwezig zijn. Een tweede categorie is die van de ’Need to haves’. Een laatste categorie
beslaat de ’Nice to haves’. Deze functionaliteiten zijn niet noodzakelijk en kunnen dus ook worden
vergeten wanneer de tijds- en gelddruk hoger worden.
Bij dit project verkreeg Bru na 6 maanden een minimum viable product, dat alle ‘Must have’ ba-
sisfuncties bezit die noodzakelijk zijn voor het functioneren van het systeem. De volgende fase in
het project focust op de ‘Need to have’ functionaliteiten. Door het werken met het minimum viable
product kon men inschatten welke van de ‘Nice to have’ functies niet meer nodig waren en kon men
beslissen om het project vervroegd te beeindigen.
Het project wordt uitgevoerd van boven naar onder. Dit is in tegenstelling tot de traditionele waterfall
techniek waar fase per fase afgewerkt wordt en van links naar rechts zou gegaan worden. In de Scrum-
methode wordt gewerkt in sprints van meestal twee weken. Deze methode wordt voornamelijk gebruikt
voor de ontwikkeling van softwareproducten omwille van zijn flexibiliteit. Voor iedere nieuwe sprint
bepaalt men de belangrijkste user stories die vervolgens moeten worden afgewerkt. Iedere user story
bezit een aantal story points dat een relatieve weergave is van het aantal mandagen werk. Deze
story points worden toegekend op basis van ervaringen met gelijkaardige activiteiten in het verleden.
55
Het gaat hier dus over een relatieve schatting in plaats van een absolute door middel van mandagen
zoals in de klassieke aanpak toegepast wordt. Na iedere sprint wordt het verbeterde softwareproduct
voorgesteld aan de product-owner in de ‘sprint review’. Hierbij kan ook de klant uitgenodigd worden
om de ontwikkelingen te bespreken en kan de product-owner nog de nodige aanpassingen suggereren.
Vervolgens volgt er een retro/evaluatie meeting waarbij alle teamleden aanwezig zijn en hun positieve
en negatieve ervaringen van de afgelopen sprint kunnen meedelen. Elk teamlid krijgt post-its en een
stift en mag vervolgens opmerkingen of vragen op een bord plakken. Daarna wordt er gestemd op
welk onderwerp de prioriteit moet krijgen om besproken te worden, waarna dit dan ook gebeurt. Op
deze manier worden de teams continu beter en hebben de leden het gevoel dat ze inspraak hebben
binnen het project.
Het voordeel van de Agile techniek is dat er op de verschillende vlakken voortdurend wordt gewerkt.
Hierdoor kan men een minimum viable product bereiken waardoor het systeem veel sneller operationeel
is en het product beter in lijn ligt met hoe het gewenst is door de klant. Door sneller met dit systeem
te gaan werken, krijg je in een vroeg stadium inzicht in wat er nog moet geımplementeerd worden en
wat overbodig is.
Voor de opvolging wordt gewerkt met een burn-up chart. Op de y-as wordt het aantal story points,
dat afgevinkt is door de product-owner, bijgehouden. De gele lijn toont het target aan. De rode lijn
toont aan welk deel van het project gedurende een gegeven sprint afgewerkt is. De blauwe lijnen tonen
per release aan hoeveel story points er nodig zullen zijn. Deze lijnen gaan respectievelijk omhoog of
omlaag wanneer er extra functionaliteiten nodig zijn of er functionaliteiten worden geschrapt. Hier
wordt gebruik gemaakt van drie releases. R1 is de release die gevormd wordt door alle must have
functionaliteiten. Deze vormen samen het minimum viable product. R2 is de release met alle need
to haves en R3 met de nice to haves. Het valt al op dat van tevoren goed was geweten welke functi-
onaliteiten zeker aanwezig moesten zijn aangezien de onderste blauwe grafiek vrijwel constant blijft.
In de grafiek van de R3 zit de meeste fluctuatie. Dit is geen burn-up chart die tot het einde van het
project loopt dus kunnen we hier niet op aflezen dat van deze functionaliteiten uiteindelijk slechts
enkele werden geımplementeerd.
56
Figuur 18: Geautomatiseerd magazijn: Burn-up chart
3.1.2.2 Voordelen van Agile PM voor Bru Textiles
� Klantgerichtheid: Scrum bezit de flexibiliteit om met nieuwe eisen en wensen om te gaan. Door
het werken in sprints geeft men aan de klant de mogelijkheid om op verschillende tijdstippen
suggesties te doen en korter op de bal te spelen.
� Significante tijdswinst: Producten worden sneller opgeleverd ten opzichte van traditioneel PM
door het werken met een minimum viable product. Wanneer dit project volgens de traditionele
aanpak zou zijn uitgevoerd, zou het volgens Verlaeckt minstens vier maanden later zijn afgele-
verd. Dit was het eerste project in de geschiedenis van Bru Textiles dat op tijd werd opgeleverd
en wekte vertrouwen op bij de CEO die nu toestaat dat de teamleden 20% van hun tijd mogen
besteden aan bijscholing van Agile technieken.
� Meer feedback: Communicatie verloopt makkelijker tussen technische mensen en de eindgebrui-
kers. Dit wordt vooral mogelijk gemaakt door het werken met user stories die in een menselijke
taal worden opgesteld. Zo is het makkelijk te begrijpen wat de verschillende eisen van de sta-
57
keholders zijn. Ook door te werken met verschillende meetings kan ook in een later stadium
worden duidelijk gemaakt aan het team wat juist gewenst wordt.
� Meer accurate tijdsinschatting: Traditioneel wordt er in mandagen geschat, wat potentieel kan
leiden tot grote fouten in de planning van nieuwe projecten aangezien er nog geen ervaringen
zijn opgedaan in die bepaalde context. Deze tijdsinschatting is ook robuuster. Je kan moeilijk
inschatten hoeveel mandagen je zal besteden aan het ontwerp van een bepaalde functionaliteit.
Agile maakt gebruik van een relatieve inschatting met behulp van story points. Op die manier
kunnen de teamleden beter inschatten hoeveel story points ze toewijzen aan bepaalde taken
omdat ze uit ervaring weten wat de inhoud is van een story point. Het geeft een meer specifieke
eenheid om inschattingen te maken.
� Empowerment: Er is een grote betrokkenheid van de teamleden door het werken in kleine teams
en omwille van de beslissingsmacht die aan hen wordt toegewezen. Ze hebben ook een duidelijk
zicht op wat zij bijdragen aan het project. De voortgang is duidelijk zichtbaar op het Scrum
task bord met vier kolommen: ‘to do’, ‘in progress’, ‘done’, ‘testing’. Wanneer een teamlid een
taak heeft voltooid, mag hij de post-it verplaatsen naar kolom ‘done’ wat dan weer voldoening
geeft.
� Lage overheadkosten: Een project dat volgens een Agile methode wordt gemanaged, is heel
beperkt in documentatie. Het project kan gevat worden in een a twee documenten. Dit brengt
dan weer een minimalisatie van de kosten gelinkt aan de administratie teweeg.
3.1.2.3 Kritische blik
Met een kleine 150 werknemers kent Bru Textiles geen ingewikkelde structuur. Daardoor is het moge-
lijk om Scrum zonder enig probleem toe te passen. De communicatie met het management verloopt
snel en moet niet langs vele verschillende stations passeren. In dergelijke structuur kan change mana-
gement heel snel gaan. Uit de getuigenis blijkt dat het management volledig achter het team staat en
de werknemers zelfs in de toekomst zal stimuleren om zich toe te leggen op Agile. Zoals eerder gesteld
is dit niet overal van toepassing en moet met zorg een framework worden uitgekozen wanneer beslist
wordt om over te gaan tot Agile.
Er valt echter op te letten met de weinige documenten die worden bijgehouden gedurende een project.
In een klassieke aanpak is het duidelijk wie er in de fout is gegaan aan de hand van het project charter.
Hier is dit echter minder duidelijk aangezien de functionaliteiten pas in de sprints worden gekozen.
58
Als het team in de fout is gegaan, wie is dan verantwoordelijk? Dit zou kunnen leiden tot problemen
wanneer een project wordt uitgevoerd voor een klant. Bij Bru Textiles is dit bij dit project nu niet
het geval, maar het is een aspect dat de moeite waard is om nader bekeken te worden.
3.1.3 IT project binnen Volvo Trucks
Volvo Trucks is een van de wereldleiders op vlak van truckfabricage. Per dag produceert het, in de
vestiging in Oostakker, 174 trucks door gebruik te maken van twee shiften. Omgerekend betekent
dit dat er elke vijf minuten een rijklare truck de fabriek verlaat. Bij de montage maakt men in deze
fabriek gebruik van twee lijnen, een snelle en een trage lijn. Binnen deze afdeling hebben wij een
project gevolgd dat uitgevoerd werd ter verbetering van het bestaande voorraadsysteem.
3.1.3.1 Projectaanpak
Zoals in de studie van PWC (2007) werd aangetoond, maakt een groot deel van de bedrijven gebruik
van een in-house ontwikkelde methode voor projectmanagement. Dit is bij Volvo Trucks ook het geval.
Het IS-GDP is een methodologie die in-house werd ontwikkeld voor het managen van IT projecten.
Figuur 19: Information System Global Development Process
In bovenstaande figuur worden de fasen waaruit het proces bestaat weergegeven. Eerst wordt het
potentieel van het idee uitgewerkt. Wat kan worden bereikt op vlak van business met dit idee? Is
het de moeite waard dat het idee wordt uitgevoerd? Daarna wordt gekeken of het idee wel degelijk
kan uitgevoerd worden. Is het mogelijk om een bepaalde techniek toe te passen binnen een zekere
omgeving? In de Development fase wordt het idee dan verder uitgewerkt en kan een voorstel tot budget
worden opgesteld. Dit is dan de fase waarin de requirements worden opgesteld en het kostenplaatje
59
hiervan kan worden ingeschat. Volvo Trucks maakt gebruik van workshops waarin de verschillende
stakeholders worden samengebracht en kunnen discussieren over de aanpak en het gewenste resultaat.
De volgende fase sluit hier eigenlijk al sterk bij aan, maar gaat nog gedetailleerder te werk. De
requirements worden individueel bekeken en hun arbeidslast wordt ingeschat. De Industrialisation
fase komt overeen met de Execution fase uit de PMBOK. Het project wordt in praktijk gebracht en
de functionaliteiten worden getest en gevalideerd. Dit snelle testen is een positief aspect in de aanpak
van Volvo Trucks en komt overeen met principes uit de Agile en Lean methodologieen. Niets laten
doorgaan zonder het getest werd en goed bevonden is, kan veel werk besparen op het einde van het
project. In de volgende fase treedt het product in voege en wordt getracht de initiele objectieven
te bereiken. In de Follow-up fase kan het product dan nog verbeterd worden om de resultaten voor
de business te optimaliseren. De gates die beslissen of er al dan niet wordt overgegaan naar de
volgende fase, worden opgesteld door de voorzitter van het Steering Committee en vallen ook onder
zijn verantwoordelijkheid.
In het IS-GDP zijn nog vier gebieden aanwezig waarop wordt gefocust gedurende het verloop van
het project. Een eerste is Business objectives management. Het houdt in dat de waarde voor het
bedrijf moet worden geıdentificeerd in elke fase en de doelen moeten voor ogen worden gehouden.
Visie en scope van het project moeten telkens worden gecontroleerd en moeten gerealiseerd worden
bij het afsluiten van het project. Een volgend gebied is dat van het Solutions management. Processen
moeten ontwikkeld worden die in lijn liggen met de objectieven. De technologie moet aanwezig zijn
om de oplossing te bereiken. Verificatie en validatie moeten duidelijk worden verzekerd in de loop van
het project. Ook Business change management is belangrijk. Dit moet ervoor zorgen dat het project
een transformatie in het bedrijf kan teweegbrengen. Dit kan door middel van communicatie, training
en roll-out. Verandering bereiken kan alleen als de stakeholders voldoende enthousiast en gemotiveerd
zijn om een succesvol project op te leveren en de objectieven te bereiken. De technische oplossingen
en processen moeten samen met de organisatie een coherent geheel vormen. Dan pas kan gesproken
worden van een project dat impact heeft op de businessomgeving. Een laatste gebied is dat van de
Project control. Alles met betrekking tot tijd, budget en kwaliteit wordt bijgehouden en aangepast
indien nodig.
60
Figuur 20: Key areas in het IS-GDP
3.1.3.2 Projectbeschrijving
Het project dat wij binnen Volvo Trucks bekeken hebben, is de opstart van het Global Material Hand-
ling System, kortweg GMHS. Met dit systeem is het de bedoeling om wereldwijd gestandaardiseerd te
werken betreffende het inventariseren van de materialen. Het GMHS is opgesteld binnen het European
Optimization Program (EOP) dat zorgde voor het uitstippelen van het tijdsplan. De keuze die men
gemaakt heeft om voor dit type systeem te kiezen was gebaseerd op STRIPE. Dit is een programma
dat beschrijft hoe Volvo Trucks wereldwijd zou moeten functioneren. Er wordt gekeken wat er wereld-
wijd aanwezig is en vervolgens wordt er een methode toegewezen. GMHS bleek dus het meest geschikt
om toe te passen binnen Volvo Trucks.
Het project ging van start met het definieren van het idee. Hierboven werd beschreven hoe men moet
tegemoet komen aan de probleemstelling. De keuze voor het GMHS was het resultaat van dit denkpro-
ces. Wat betreft de planning van het project werd gekozen om het project op te delen in verschillende
subprojecten. De start van subproject 1 vond plaats in week 23. Gedurende de eerste vijf weken zou-
den de requirements in detail geanalyseerd worden, vervolgens komen de testperiode, de ontwikkeling,
de configuratie, opleiding, de proefperiode en het go-live moment. De andere subprojecten zouden in
week 39 van start gaan. Subproject 1 beslaat de implementatie van het IT-systeem voor de Cabtrim
(CT) afdeling. Subproject 3 is het project voor de Final Assembly (FA) en subproject 5 is voor het
administratieve systeem met betrekking tot de receptie van de goederen. Subprojecten 2 en 4 werden
in het verleden al succesvol afgerond en dus was verdere opvolging hiervoor niet vereist.
61
Figuur 21: Verloop van ‘Subproject 1’
Figuur 22: Verloop van ‘Subproject 3’
In week 46 van 2014 werd beslist een workshop te organiseren. Hier werd samengezeten met iedereen
die bij het project betrokken was. Iedereen kreeg dezelfde twee vragen voorgeschoteld: ‘Wat zijn de
dingen die je wilt behouden?’ en ‘Wat zou je willen dat je nu niet hebt?’. Deze requirements werden
gebundeld en gefilterd. Het kan immers dat sommige zaken al mogelijk waren volgens bepaalde mensen.
Wanneer dat het geval was, moesten degene die dat beweerde en de persoon die dat bepaalde verzoek
had, samenkomen. De ene persoon moest het dus aan de andere aanleren om die bepaalde functie uit
te voeren met behulp van het programma. In de requirements werden gradaties toegevoegd. Wanneer
de requirements bestempeld werden met ‘MUST’, dan betekende dit dat het een showstopper was. Als
ze die functie niet zouden hebben, kunnen er geen trucks gebouwd worden. De ‘NEED’ requirements
hebben een zekere impact op het EOP. Met name, als die functie niet aanwezig is, is het systeem niet
efficient. Als laatste is er nog ‘NICE TO HAVE’. Dit zijn requirements die niet echt nodig zijn maar
het geheel aantrekkelijker zouden maken. In een Lean of Agile benadering zouden deze als allerlaatste
worden gehouden en waarschijnlijk zelfs niet meer uitgevoerd worden omdat ze aanzien worden als
verspilling of weinig waarde toevoegend.
62
Figuur 23: Planning na de workshop in week 46
Na de workshop in week 46 stond gepland dat het Cabtrim experiment zou worden opgestart. Dit
hield in dat de twee productielijnen zouden worden omgewisseld van plaats. Omwille van IT-problemen
werd het experiment met vier weken uitgesteld in het EOP. Dit paste echter niet binnen de agenda
van de lokale managers en er werd een compromis gezocht. Men besliste dan om een stap in Cabtrim
te doen zodat de mensen er al zouden kunnen mee werken. Later zou dan in een Big Bang na de
zomer het volledige experiment vervolledigd worden.
Figuur 24: Vertraging in ‘Subproject 1’
De blauwe activiteiten zijn degene van subproject 1 en de groene van subproject 3. In de volgende
afbeelding is zichtbaar dat door de vertraging van subproject 1 er een conflict ontstaat met activiteiten
van subproject 3 wanneer de milestones van dit project volgens het EOP worden toegepast.
63
Figuur 25: Conflict van ‘Subproject 1’ met ‘Subproject 3’
Om dit probleem op te lossen, werden de activiteiten uitgesplitst. De eerste fase in Cabtrim werd
uitgevoerd volgens plan zodat de mensen ermee konden leren werken, maar de volledige uitwerking
van Cabtrim werd gehouden voor na de zomer in plaats van alles in de zomer te lanceren. Op die
manier werden de problemen in Cabtrim duidelijk zichtbaar en kon er geleerd worden uit de fouten
met het oog op de implementatie van het systeem in de final assembly.
Figuur 26: Oplossing voor het conflict van ‘Subproject 1’ met ‘Subproject 3’
Vervolgens werden twee activiteiten verschoven naar een latere datum. Hun Go live momenten gaan
van respectievelijk week 17 en week 23 naar week 33, waar ze samen zouden gelanceerd worden.
64
Figuur 27: Vertraging in het EOP tijdsplan
In dit kostenoverzicht kan men zien dat de personeelskosten de verwachte kosten op het moment van
de observatie (P08) niet overstijgen. Ook bij de materiaalkosten is dit het geval. Dit toont aan dat
het project ook op kostenvlak het aangegeven plan niet volgt. In de toekomst zullen de kosten hoger
oplopen dan de geschatte budgetten wegens te veel uitgestelde activiteiten gedurende het project tot
nu toe.
65
Figuur 28: Kostenoverzicht van het project
3.1.3.3 Kritische blik
De methode die Volvo Trucks gebruikt, is vooral gericht op het vertalen van de voortgang van het
project naar de oversten. Door middel van PowerPoint10 worden slides opgemaakt die gepresenteerd
worden aan het management. Hierin wordt visueel op tijdlijnen voorgesteld wat de voortgang is van
het project. De manier waarop het project in realiteit wordt geleid is eerder rommelig en er wordt
veel teruggekomen op een eerdere planning. Het is vooral in de uitvoerende fase dat de controle over
10Microsoft PowerPoint
66
het project te wensen overlaat. De voorbereidende fasen zijn wel duidelijk gestructureerd en proberen
om een zo efficient mogelijke oplossing te ontwikkelen voor het gestelde probleem. De oplossing wordt
in elk van zijn facetten geevalueerd alvorens het geconfirmeerd wordt en wordt overgegaan naar de
volgende fase. Het zou de projectresultaten zeker ten goede komen als er beter gebruik zou gemaakt
worden van goeie controleprocessen en processen die wel degelijk monitoren hoeveel voortgang wordt
gemaakt met oog op het vooropgestelde eindresultaat. In de key areas zijn zeker processen aanwezig
die hiervoor moeten zorgen maar onze observatie leert dat deze niet voldoende zijn. De intentie is
zeker aanwezig om de projecten op een juiste manier aan te pakken, maar dit wordt in de praktijk
onvoldoende toegepast in het departement van Volvo Trucks in Oostakker. Ook zou het efficienter
zijn als ze zouden gebruik maken van een betere tool om hun projecten te managen zoals Microsoft
Project, Primavera of ProTrack waarin het mogelijk is om het totaalplaatje, inclusief de vastgelegde
structuur, goed onder controle te houden.
3.2 Constructieprojecten
3.2.1 Aanpak en mogelijkheden voor andere methodes
3.2.1.1 Klassieke aanpak
Volgens Owen, Koskela, Henrich en Codinhoto (2006) is het mogelijk om een constructieproject op te
delen in drie grote deelprojecten: pre-design, design en constructie. Gewoonlijk worden deze projecten
volgens de klassieke waterfallmethode aangepakt, waarin het project lineair de verschillende fasen
doorloopt zoals initieel gepland staat en er eventueel ook kan teruggekoppeld worden wanneer een
aanpassing nodig is. De pre-design fase vormt de basis voor de andere fasen. De drie hoofdzaken in
deze fase zijn de concept ontwikkeling, de planning van de aankoop, het tijd en het budget en het
opstellen van het document met de stakeholders en requirements. Deze fase is typisch gekenmerkt
door een hoge complexiteit gezien de moeilijkheid van het definieren van de requirements. Dikwijls
resulteert het in onvolledige, inconsistente informatie waarop de volgende fasen dan gebaseerd worden.
De volgende fase, de designfase, zal instaan voor het vertalen van het concept dat gegenereerd werd in
de pre-design fase naar een concreet plan dat oplossingen biedt voor de initieel gestelde problemen. De
laatste fase is die van de executie of constructie. In deze fase ligt de focus op het engageren van mensen
om het project uit te voeren zoals gepland en concreet te monitoren en controleren wat uitgevoerd
werd en nog moet uitgevoerd worden.
67
3.2.1.2 Lean aanpak
Lean projectmanagement kan goed werken in statische omgevingen. Daarom kan het mogelijk zijn om
Lean toe te passen in de executiefase van een constructieproject waar de flow van activiteiten goed op
elkaar volgt. Aangezien in een constructieomgeving bepaalde bouwprocessen ook steeds terugkeren, is
een filosofie van continue verbetering en bijleren zeker een meerwaarde. In de voorbereidende fasen is
het weinig nuttig om Lean te gaan toepassen gezien de hoge graad aan onzekerheid en het dynamische
karakter van de activiteiten. Verspillingen van onder andere tijd worden weggewerkt wat ervoor zorgt
dat het proces te gevoelig zal zijn voor veranderingen. Het resulterende proces zal bijgevolg vooral
toepasbaar zijn in statische omgevingen. (Demir et al., 2014)
3.2.1.3 Agile aanpak
Owen et al.(2006) hebben in hun werk onderzoek gevoerd naar de mogelijkheid om constructieprojecten
uit te voeren met behulp van de Agile methode. Hiervoor hebben ze geprobeerd om tijdens elke
vooropgestelde fase te evalueren of de principes van Agile een meerwaarde zouden kunnen bieden. De
resultaten worden in volgende alinea gegeven.
Zoals gesteld is de pre-design fase gekenmerkt door hoge complexiteit. Dit is vooral omwille van de
moeilijkheidsgraad om requirements te definieren. Op vlak van het definieren van de requirements
biedt Agile zeker voordelen. Via veelvuldige meetings met de klant, kan duidelijk worden wat juist
gewenst is in het project. Verder kan ook een sterk, veelzijdig team voordelen opleveren ten opzichte
van een klassiek team, dat een lagere frequentie aan communicatie bezit. Op vlak van aanpak van
ontwikkeling van het project, kan een iteratieve aanpak zoals Agile ook grote voordelen bieden. Dit
omwille van de nood aan integratie en betrokkenheid van de klant.
De designfase tracht de basis die gelegd wordt in de pre-design te implementeren en te vertalen naar
de constructiefase. De integratie tussen het initiele plan en de constructie is hier van groot belang.
Owen en Koskela argumenteren dat deze fase heel specifiek is per project. Een groot probleem blijft
de kloof die bestaat tussen de gewenste en de verkregen requirements. Hoge betrokkenheid van de
klant is typisch heel gewenst in de ontwikkeling van een constructieproject.
In de constructiefase is het moeilijker om Agile toe te passen. Aangezien de werknemers niet werkzaam
zijn in de hoogst verdienende sector, zal de culturele weerspannigheid groter zijn tegenover nieuwe
methodes die moeten aangeleerd worden. Het Agile manifesto schrijft immers voor dat de werknemers
omgeschoold moeten worden door middel van intensieve training. Een tweede moeilijkheid is dat in
68
constructieprojecten dikwijls wordt gewerkt met onderaannemers en tijdelijke werkkrachten, waardoor
bijna niet mogelijk is om veranderingen door te voeren met betrekking tot de manier van werken. Enkel
op vlak van planning zou er kunnen Agile gewerkt worden en zo de wensen van de klant frequent op
te nemen in het takenpakket.
Concluderend kunnen we dus stellen dat Agile enkel zou kunnen toegepast worden in de eerste fasen
van het project. Vooral in het definieren van de requirements liggen de mogelijkheden. Ook het feit
dat de organisatie meer zal bijleren en de werknemers meer gericht zullen zijn op verandering en meer
gemotiveerd zullen zijn, kan zeker een gunstig effect teweegbrengen. In de executiefase van een project
zal dit echter moeilijk zijn om over te schakelen naar Agile. Onderaannemers en tijdelijke werkkrachten
maken het zeer moeilijk om de overgang te maken.
3.2.2 Constructieproject Antwerpen
3.2.2.1 Projectbeschrijving
Van het constructieproject dat hier dienst doet als praktisch voorbeeld kunnen we omwille van NDA‘s
de naam van de projectontwikkelaar, van wie het gebouw eigendom is, niet vrijgeven. Dit zou toch
geen grote meerwaarde leveren bij de bespreking van het project. Het gaat om een project voor de
herinrichting van een kantoorgebouw in Antwerpen met als doel het opfrissen van het gebouw om zo
de aantrekkelijkheid te verhogen. Samen met de facelift, worden ook appartementen ondergebracht in
het gebouw. Aangezien een constructie-omgeving strikt gereguleerd is en men zich dus moet houden
aan het vooropgestelde ‘Ruimtelijk Structuurplan’11, is de klassieke aanpak de aangewezen methode.
Bij de bouw of renovatie van een gebouw dient steeds eenzelfde procedure gevolgd te worden met
betrekking tot de aanvraag van diverse vergunningen. Dit proces kan vertragingen oplopen, maar
voor bouwbedrijven is dit meer de standaard dan de uitzondering. Het is onmogelijk om te bouw
te laten starten alvorens de vergunningen verkregen zijn. De traditionele waterfall aanpak is hier
toegepast zoals kan gezien worden in de design- en ontwikkelingsfase van het project.
Figuur 29: Verloop van project in traditioneel projectmanagement
11Ruimtelijk Structuurplan Vlaanderen, opgesteld door de Vlaamse Overheid sinds 1997 - rsv.ruimtevlaanderen.be
69
In de scope fase werd het verloop van het project overeengekomen in overleg met de klant. Eerst en
vooral moet de binneninrichting worden aangepakt alsook de bouw van flats in de bovenste verdiepin-
gen. In een later stadium zal ook de buitengevel een facelift krijgen. Vervolgens werd overgegaan naar
de designfase waarin de bouwonderneming onderzoek voert naar de diverse vereisten en vergunningen.
Ook een ontwerp werd gemaakt conform de wensen van de klant. Deze fase nam zes maanden in
beslag.
Figuur 30: Designfase van het constructieproject
De volgende fase is de ontwikkelingsfase. Hier worden de vergunningen verkregen. Deze fase kan
van start gaan wanneer de vergunningen opgesteld en vervolgens ingediend zijn. Dit gebeurde op 24
februari 2014. Men verwachtte dat alle vergunningen binnen de zeven maanden verkregen zouden
70
zijn. Aangezien deze fase makkelijk slachtoffer kan zijn voor vertragingen, moeten de activiteiten goed
opgevolgd worden. Wanneer de vergunningen niet aanvaard worden, dienen deze te worden herzien,
wat een mogelijke extra tijds- en budgetlast met zich mee kan brengen.
Figuur 31: Ontwikkelingsfase van het constructieproject
De implementatiefase is gestart nadat de vergunningen verkregen zijn, met name begin 2015. De
renovatie van de buitengevel zal pas van start gaan midden 2016. De totale duur van de bouw zou drie
jaar in beslag nemen. Wanneer de implementatiefase voltooid is, wordt overgegaan naar de ‘toezicht-
en controlefase’. Wanneer het gebouw wordt goedgekeurd, kan het project afgesloten worden.
3.2.2.2 Kritische blik
Voor constructieprojecten zijn er weinig alternatieven voor de klassieke projectaanpak. Je kan zoals
eerder vermeld wel Agile gebruiken om de eerste fasen van het project op te leveren. Lean zou
dan kunnen gebruikt worden in de constructiefase. Agile kan toegepast worden in het definieren
van de requirements om zo het effect te hebben van focusgroepen die dieper ingaan op de scope.
Feedback van de klant zou dan beter gecapteerd kunnen worden. Lean heeft verschillende voordelen
71
wanneer het in een statische omgeving wordt gebruikt waar weinig onverwachte zaken gebeuren. Dan
kan het hebben van een proces waar de verspillingen geminimaliseerd zijn grote voordelen opleveren.
Wanneer dan teruggekoppeld wordt naar de constructie-omgeving, moet dan wel gesteld worden dat
een constructieproject in de executiefase nog steeds niet vrij is van onverwachte zaken. Deze sector is
onder andere sterk afhankelijk van de weersomstandigheden waardoor dergelijke aanpak dan weer aan
geloofwaardigheid zou inboeten. Aangezien Lean PM gebruik maakt van het last planner principe,
is het extra gevoelig voor vertragingen opgelopen door extreme weersomstandigheden of onverwachte
gebeurtenissen. Door de afwezigheid van buffers, kan dit serieuze gevolgen hebben voor de tijd en dus
ook indirect voor de andere constraints.
3.3 Overheidsprojecten
3.3.1 Constructie project Station Gent Sint Pieters
De bouw van het treinstation Gent Sint-Pieters werd afgerond in 1913 ter voorbereiding van de we-
reldtentoonstelling in datzelfde jaar. Het aantal reizigers per dag verhoogde van 37.000 per dag in
2007 naar 54.000 in 2014. Project Gent Sint-Pieters is een lopend project met als doel het station en
zijn omgeving aan te passen aan de uitdagingen van de 21ste eeuw. Meer specifiek werd bepaald dat
volgende 2 hoofddoelstellingen moesten voldaan zijn op het einde van het project:
� De omgeving van het station moet meer flexibel, leefbaar en amusant worden. De omgeving
wordt een mix van wonen en werk.
� De verschillende transportmiddelen in de omgeving van het station (publiek en privaat) moeten
beter op elkaar afgestemd zijn.
Omwille van zijn omvang werd het project onderverdeeld in 10 verschillende deelprojecten. In elk van
deze deelprojecten had minstens een van de 6 verschillende partners een belangrijke rol. Het einde
van het constructieproject Gent Sint-Pieters was initieel gepland voor eind 2016, maar omwille van
verschillende redenen zal het project pas in 2024 afgerond worden.
3.3.1.1 Projectbeschrijving
Het project Gent Sint-Pieters startte in juli 2004 met een algemene overeenkomst tussen de partners
NMBS, Infrabel, De Lijn, Agentschap Wegen en Verkeer, Stad Gent en Eurostation. Pas in april 2007
kon de bouw van de externe omgeving starten (Mijlpaal 1). De twee hoofdredenen hiervoor waren:
72
� Problemen bij het vinden van fondsen
� Vertragingen bij het verkrijgen van de verschillende bouwvergunningen (beschermd monument)
Het project werd vervolgens opgedeeld in twee grote subprojecten: GSP070 en GSP080. Het eerste
subproject GSP070 omvat de constructie van de eerste 3 platformen voor de bouw van perron 12 tem
8. In het tweede deelproject GSP080 zullen de laatste 4 platformen worden gebouwd met de perrons
7 tem 1. Het opdelen van het project in twee grote subprojecten en 7 fasen versterkt het leerproces
en dit brengt enkele voordelen met zich mee:
� Het verminderen van het aantal fouten
� Het verkrijgen van een meer accurate planning
Doordat men eerst de eerste drie platforms bouwt, krijgen de managers en aannemers een duidelijker
beeld over de moeilijkheden en uitdagingen van het project. Bij de uitvoering van het project zal
heel wat nieuwe informatie en kennis verworven worden, die men kan gebruiken voor de planning en
uitvoering van GSP080. Door het verminderen van het aantal fouten zullen ook de kosten aanzienlijk
dalen.
Figuur 32: Overzicht van de verschillende fasen in het GSP-project
Op 1 november 2010 (Mijlpaal 2) startte de bouw van de perrons met de officiele start van subproject
GSP070, die handelt over de bouw van perron 12-8. Op 5 november 2010 (Mijlpaal 3) beginnen de
werken aan perron 12 (fase 1), waarvan het einde van deze constructie gepland waren voor 1 augustus
2012 (Mijlpaal 4). De eigenlijke afwerking van perron 12 was 3 maanden later dan gepland (Mijlpaal
5). Door deze vertraging kon de bouw van perron 11(fase 2) pas starten op 5 november 2012 (Mijlpaal
6). Het geplande einde van deze activiteit was 1 september 2014 (Mijlpaal 7). Om deze deadline te
halen besloot de projectleider om te werken in shiften, zodat alle mogelijk tijd werd gebruikt. Volgens
73
zijn berekening bespaarde men zo 70 tot 80 kalenderdagen per fase. Daarbovenop werd ook een nieuwe
techniek geıntroduceerd, de Stross methode of wanden-dakmethode. De bouw van perron 11 eindigde
op 4 juni 2014 (Mijlpaal 8), 3 maanden eerder dan aanvankelijk gedacht. Dankzij deze ingreep heeft
het team de vertragingen opgelopen bij de bouw van perron 12 goed kunnen maken. De wanden-
dakmethode maakt het mogelijk dat de boven-en onderbouw gelijktijdig gebeuren. Deze techniek kan
de constructie tijd significant verminderen. De afwerking van subproject GSP070 staat gepland voor
1 september 2017 (Mijlpaal 9). Het tweede subproject GSP080 zal kort hierna starten (Mijlpaal 10).
De oplevering van de bouw van de externe omgeving is gepland voor 1 juli 2024 (Mijlpaal 11). De
voltooiing van subproject GSP080 zou plaatsvinden rond 1 augustus 2024 (Mijlpaal 12). Project Gent
Sint-Pieters eindigt normaal op 1 oktober 2024.
Figuur 33: Overzicht van de verschillende mijlpalen in het GSP-project
Voor het plannen van het project werd MS Project gebruikt. In het begin maakte men enkel gebruik
van alle Finish-Start linken. Verder werden de minimale vereiste vertragingen tussen activiteiten ook
opgesteld. Doordat de bouw van perron 12 eindigde met een vertraging van 3 maanden, voegde men
bij het plannen van constructie van de overige perrons Start-Start linken toe. Dankzij deze techniek
kon de boven- en onderbouw gelijktijdig verlopen en werden de opgelopen vertragingen goedgemaakt.
74
Figuur 34: Detailplan met de activiteiten voor de bouw van perron 11
Voor het plannen van dit project is het belangrijk om naar de belangrijkste doelstelling te kijken.
Hierin werd steeds de volgende afnemende orde van belangrijkheid gebruikt: Kwaliteit - Minimalisatie
van de totale kosten - Minimalisatie van de duurtijd. Het doel is om een modern station te bouwen
dat voor de komende 100 jaar de wensen van de reizigers kan verwezenlijken. Het belang van de
minimalisatie van de tijd is miniem, zoals in de meeste overheidsprojecten.
75
3.3.1.2 Kritische blik
Project Gent Sint Pieters maakt voornamelijk gebruik van twee Lean principes:
� Bouw kwaliteit in
� Versterken van het leerproces
Kwaliteit was de belangrijkste doelstelling voor dit project, aangezien het de wensen van de reizigers
voor de komende 100 jaar zou moeten verwezenlijken. De opdeling van het project in verschillende
fasen versterkt het leerproces enorm. Er wordt geleerd van fouten uit het verleden en men houdt hier
rekening mee in de toekomst.
Door de hoofdzakelijke focus op de kwaliteit, wordt weinig rekening gehouden met de tijd. De project
sponsor hecht weinig belang aan het al dan niet op tijd afleveren van het project. Het oorspronke-
lijke tijdsplan wordt bij overheidsprojecten zeer optimistisch opgesteld omwille van politieke redenen.
Indien men bij het begin had voorspeld dat het project tot 2024 zou lopen, dan zou het project waar-
schijnlijk niet worden goedgekeurd. De bedoeling van het project is een duurzaam station te creeren
waar goed over nagedacht is met oog op de toekomst. De termijn van oplevering is daarbij van weinig
belang. Aangezien voor dit project de kwaliteit het allerbelangrijkste is, raden wij het gebruik van
een veelzijdiger tool zoals ProTrack of Primavera aan. Plannen met een van deze twee tools maakt
het mogelijk zich te richten op zowel kwaliteit als kostenminimalisatie. Bij MS Project ligt de focus
op minimalisatie van de tijd.
3.4 Projecten in de banksector
Banken zijn vandaag de dag instituten die heel sterk IT-gestuurd worden. Dit heeft als resultaat dat ze
veel lopende projecten hebben die gericht zijn op het ontwikkelen van applicaties die het gebruiksgemak
voor de klanten tot een hoger niveau tillen. Hierdoor zijn ze heel sterk bezig met het in kaart brengen
van de Agile methode. Bezoeken aan zowel BNP Parisbas, KBC en ING hebben aangetoond dat
elk van de drie banken actief gebruik maakt van Agile voor het ontwikkelen van apps en financiele
platformen.
3.4.1 Projectaanpak bij ING
ING Belgie is bezig met de overgang van klassiek projectmanagement naar Agile projectmanagement.
ING Nederland probeerde deze transformatie 3 jaar geleden al in te zetten door het gebruik van de
76
Scrum methode. Individuele Scrum-teams werden opgezet en werkten gedurende een jaar aan een
bepaald project. Deze transformatie liep aanvankelijk tamelijk positief. Na 1 jaar werd echter wel
duidelijk dat de verschillende lagen in de organisatie niet in lijn waren met elkaar waardoor heel
wat projecten vastliepen of projecten werden opgeleverd die niet strookten met het initiele plan. Het
probleem hier is dat de objectieven die werden opgelegd op strategisch niveau niet goed werden vertaald
in de projecten. De teams leverden een product op dat het resultaat was van individuele prioritisering
op basis van hun eigen preferenties. Dit was in de beginfase van Agile het grote probleem en is zoals
eerder vermeld ook de oorzaak waarom klassieke denkers nog steeds weigerachtig staan tegenover
Agile. Zo kan worden geıllustreerd hoe Agile niet moet toegepast worden. Ook Chris Kindermans
hamerde er in onze interviews telkens op dat men nooit mag vergeten waarom men het project gestart
heeft. Het is steeds het management die een probleem wilt oplossen en waarvoor blijkt dat de baten
de kosten zullen overschrijden. Indien dit niet het geval is, zal dit een verspilling zijn van resources.
In zijn ogen komt Scrum als framework in dit opzicht tekort.
ING Belgie wilde deze fouten niet meer maken en startte in 2015 met de implementatie van het Scale
Agile Framework (SAFe) van Dean Leffingwell. Deze methode is erop gericht om zowel principes van
Lean en Agile te integreren in een projectmanagement methodiek. De overgang van een klassieke
projectomgeving naar dergelijke nieuwe omgeving werd door Leffingwell beschreven in verschillende
aandachtspunten. Een eerste is de overgang van centrale controle naar gedecentraliseerde beslissings-
macht voor de teams zelf. Het team moet de nodige zelfstandigheid en vertrouwen krijgen om zelf
het project in handen te nemen. Volgens Eric Martens, project mangager bij ING, was dit het be-
langrijkste en tevens moeilijkste aspect van hun overgang naar Agile. Wanneer je het team niet de
nodige zelfstandigheid kan bieden, kan volgens hem de overgang niet slagen. Een tweede is om actief
de vraag te gaan managen. De scope van het project moet worden opgedeeld in verschillende sprints.
Op die manier kan het opleveren van de verschillende onderdelen op een continue manier gebeuren.
In plaats van gedetailleerde projectplannen op te stellen waar alles nauwkeurig is vastgelegd, moet
worden overgegaan naar een aanpak die specifiek is voor elke sprint. Dit vergt heel wat moeilijkheden.
Sommige bedrijven beschrijven in het begin van het project wat in elke sprint moet uitgevoerd worden.
Ze behouden dus nog het centrale planningsaspect van de klassieke aanpak. Dit is een meer genu-
anceerde aanpak van Agile en is ook veiliger om het budget in te schatten. Traditioneel wordt deze
scope opgedeeld door een Work Breakdown Structure om zo te kunnen werken met functionaliteiten
die minder omslachtig zijn. In Agile worden deze functionaliteiten omgezet in story points om zo nog
beter te kunnen inschatten hoeveel tijd en welk budget het project nodig heeft. De omschakeling naar
77
deze manier van werken is dus een belangrijk aspect om goeie inschattingen te kunnen maken en kan
cruciaal zijn in de projectopvolging. Een laatste relevant punt is de verandering op vlak van mijlpalen.
In traditionele projecten wordt gewerkt met vaste mijlpalen doorheen het project. In een Agile project
zijn de maatstaven en mijlpalen gebaseerd op de gerealiseerde voortgang in het project.
In SAFe is het vooral belangrijk dat de voeling met het strategische niveau verzekerd wordt. Agile
kan dit uit het oog verliezen als er geen steun is door andere methodieken. Door een Agile-methodiek
uit te breiden naar SAFe, kan dit voorkomen worden. Het is een kennis gebaseerd programma dat een
bedrijf in staat stelt om zijn Lean/Agile methodieken toe te passen op ondernemingsniveau. SAFe
werd ontwikkeld door Dean Leffingwell zodat ook grote organisaties met meer dan 1000 personen in
IT en meer dan 250 in de software ontwikkeling in een Agile omgeving kunnen werken. Het bestaat
uit drie grote lagen: portfolio, programma en team. De portfoliovisie waarborgt de wensen van het
investeringsteam, de strategie en de verschillende waardestromen. Op het programmaniveau werken
een 50 a 125 personen aan een programma. Op de onderste laag bevindt zich het team niveau. Scrum,
extreme programming en andere methodes focussen op dit niveau en gaan niet verder. Dit is een
groot minpunt van deze methodes, aangezien hierdoor vaak de connectie met de businesskant en dus
de hoger liggende lagen verloren gaat. SAFe waarborgt dus een uniforme weergave van het werk dat
het topmanagement toelaat om topdown te kijken indien extra informatie gewenst. Verder kan er ook
gestart worden vanuit de teams om nieuwe trends te ontdekken en voor het uitvoeren van verschillende
analyses.
78
Figuur 35: Scaled Agile Framework
SAFe teams bestaan meestal uit 8 a 10 personen met daarin zowel ontwikkelaars als operationele
werkkrachten. De productowner bepaalt de belangrijkheid van de verschillende stories die in de backlog
van de teams staat. Op deze manier blijft de connectie met de corebusiness behouden. Op het
programmaniveau komen alle stories te samen die met een applicatie te maken hebben. Tot slot
brengt het portfolio al deze applicaties samen. De overgang van klassiek projectmanagement naar het
gebruik van het SAFe model zorgt ervoor dat ieder team om de 3 maanden een set van functionaliteiten
kan opleveren.
ING maakte de overstap van waterfall volgens PRINCE naar SAFe. De hoofdreden die zij hiervoor
zagen was dat ze met de klassieke aanpak te veel tijd moesten spenderen aan het documenteren van
het project. Wanneer je bezig bent met deze documentatie, evolueert de markt verder en bestaat de
mogelijkheid dat het al te laat is om het eindproduct nog te lanceren. Met de huidige methode achten ze
het mogelijk om na gemiddeld drie maanden al en product op te leveren en dus makkelijker in te spelen
79
op de markt. Martens is positief over de transformatie die binnen ING Belgie gebeurt. Deze nieuwe
aanpak werkt motiverend voor het team, is goedkoper en de time-to-market is ook verminderd. Door
het werken met vaste teams is de strijd die gepaard gaat met de toewijzing van de beste werknemers
tot het project drastisch gedaald.
Daarnaast is de overgang verre van makkelijk. De grootste moeilijkheden bestaan in de drill-down
van de objectieven. Het is moeilijk om high level objectieven op te delen in Epics, vervolgens in High
level features en tenslotte in features. Ook het probleem om te rapporteren komt aan de oppervlakte.
Het topmanagement verwacht dat een degelijke rapportering steeds aanwezig is zodat het voor hen
mogelijk is om een zekere vorm van controle uit te oefenen. Wanneer gebruik gemaakt wordt van Agile
is het de bedoeling dat deze rapportering tot een minimum beperkt wordt.
Een volgende moeilijkheid situeert zich op het niveau van risico en business case. Het is moeilijk om
aan een opdracht te beginnen wanneer je niet kan staven wat je juist zal opleveren en waaraan je dus
het budget zal spenderen. De mensen van het risicodepartement zijn heel oncomfortabel met deze
manier van werken en vormen dus een bron van weerspannigheid. Men mag echter nooit vergeten dat
men geen project zal starten indien de baten de kosten niet zullen overschrijden.
Zoals eerder gezegd moet een trade-off worden gemaakt tussen het op een iteratieve manier te werk
gaan in het ontwikkelen van het product en het van in het begin vastleggen van de functionaliteiten en
requirements die nodig zijn. Het idyllische plaatje waarin het team veel vrijheid krijgt om het product
te ontwikkelen moet genuanceerd worden.
Volgens Martens zou de overstap naar het SAFe framework met ongeveer 30 a 40 % kostenbeperking
kunnen gepaard gaan als iedereen zou meewerken en de methodiek ten volle zou begrijpen.
3.4.2 PARIS-Project binnen KBC
3.4.2.1 Projectbeschrijving
Een andere illustratie van de Agile aanpak binnen de banksector is die van KBC. De manier volgens
dewelke KBC werkt, is gelijkaardig als die van Bru Textiles. Het project dat wij binnen KBC hebben
gevolgd is het PARIS project, wat staat voor Price and Rate Information System. Het is een systeem
dat marktdata zoals wisselkoersen, interest rates, obligatiekoersen en aandelenkoersen verzamelt van
verschillende bronnen. Vervolgens zal het de outliers detecteren en corrigeren. Van de interestwaarden
berekent men rentecurves en deze distribueert men dan naar interne afnemers.
Het systeem wordt als een product beschouwd, waarbij de productbacklog voortdurend wordt gevoed
80
met nieuwe functionaliteiten, die dan iteratief worden opgeleverd. Het team is een long lived team,
wat inhoudt dat dezelfde mensen al een hele tijd betrokken zijn bij de ontwikkeling van dit systeem.
Dit toont aan dat niet alle Agile projecten op korte termijn lopen. Dit project loopt al enkele jaren
en het is erop gericht om het bestaande systeem telkens te updaten, wat natuurlijk impliceert dat het
team mensen moet bevatten die heel goed met het systeem vertrouwd zijn en dus al gedurende een
lange periode deel uitmaken van het team.
Het project is opgedeeld in verschillende gebieden waaraan parallel wordt gewerkt. Dit zijn bijvoor-
beeld de issuers, migration funds, aandelen en twijfelzone,... Deze gebieden kunnen teruggevonden
worden in de Burn-up chart die is opgesteld om een globaal beeld te behouden van het project. In
deze burn-up chart wordt voortgang geboekt door in de verschillende parallelle gebieden te werk te
gaan. De figuur toont mooi de verschillende fasen naast elkaar en de algemene voortgang. De voort-
gang per gebied wordt hier niet gegeven.
Figuur 36: Burn-Up chart van het PARIS project
De volgende figuur toont wel de voortgang per gebied. Hier wordt duidelijk gemaakt hoe ingewikkeld
het wordt wanneer verschillende fasen parallel worden uitgevoerd. In de figuur kan ook gezien worden
dat er verschillende cut-off points worden vastgelegd. Dit zijn momenten waarop telkens een deel van
het product wordt opgeleverd.
81
Figuur 37: Burn-Up chart van het PARIS project per gebied
Een sprint beslaat activiteiten in elk gebied. Bij de planning van een sprint wordt telkens eerst een
backlog gemaakt. Aan de taken die in de backlog gepland staan, worden story points toegekend om
een inschatting te geven met betrekking tot de werklast die gepaard gaat met de taak. Op basis van die
story points wordt dan een capaciteitsplanning gemaakt die weergeeft hoeveel story points nodig zijn
in de sprint en hoeveel er voorhanden zijn onder vorm van teamleden. Aan een teamlid dat gedurende
de sprint voltijds aanwezig is, kan een totaal van 10 punten toegewezen worden. Voor een voorbeeld
van dergelijke capaciteitsplanning wordt verwezen naar onderstaande figuur.
82
Figuur 38: Capaciteitsplanning PARIS
In deze capaciteitsplanning kan aan de rechterzijde gezien worden welke functies de teamleden uitoefe-
nen. Het multidisciplinair team is hier zeker van toepassing. Zowel technische, functionele en business
mensen zijn aanwezig gedurende het project.
Ook de individuele sprints worden van een burn-up en burn-down chart voorzien. Bij de sprint
story burn-down charts maken ze een voorstelling van hoeveel storypoints gedurende een bepaalde
sprint moeten geımplementeerd worden. De capaciteit die gedurende de sprint beschikbaar is, wordt
voorgesteld in het blauw. Dit zijn de eenheden die tonen hoeveel tijd teamleden beschikbaar zijn
voor het project en meer bepaald deze sprint. Er moet getracht worden om alle story points te
implementeren voor het einde van de sprint. Deze figuur toont dat voorgesteld wordt om iedere dag
negen story points te implementeren. Dit is in realiteit echter niet mogelijk, wat ook wordt aangetoond
door de groene grafiek. Op de laatste dag moesten nog 35 storypoints worden geımplementeerd, wat
natuurlijk geen ideaal scenario is.
83
Figuur 39: Sprint Story Burn-down chart PARIS
In een sprint item burn-up chart wordt gevisualiseerd hoeveel items in een sprint moeten geımplementeerd
worden en wat de status is op de verschillende dagen. Het grote verschil met de sprint story burn-
down chart is dat er in de burn-up chart gewerkt wordt met items in plaats van story points. De drie
onderliggende curves wordt weergeven welke items in progress, on hold of in de wachtrij zitten voor
elke sprint.
Figuur 40: Sprint Item Burn-up chart PARIS
84
Extra KPI’s die door KBC worden bijgehouden in een Agile project zijn de snelheid (velocity), het
budget en de business capacity. De snelheid wordt in onderstaande grafiek uitgedrukt in het gemid-
deld aantal story points die per werkdag worden uitgevoerd. Aangezien een sprint tien werkdagen
beslaat, wordt het aantal story points per sprint gedeeld door tien. Hier kan worden opgemerkt dat de
gemiddelde snelheid per sprint meestal lager ligt dan wat initieel gepland werd. Waarschijnlijk ligt dit
aan het feit dat sommige taken hoger werden ingeschat en dus meer story points werden toegewezen
dan eigenlijk nodig was. De stories konden dus meestal in minder tijd worden voltooid.
Figuur 41: Controle van de snelheid per sprint
Ook wordt de gemiddelde snelheid per werknemer per werkuur bijgehouden. Het aantal story points
wordt dan gedeeld door het totaal aantal werkuren van alle werknemers. Deze snelheden worden
per sprint vergeleken en oorzaken worden gezocht die kunnen verklaren waarom de snelheid hoger of
lager ligt in een bepaalde sprint. Dit laat toe om kort op de bal te spelen met betrekking tot de
productiviteit van de werknemers.
Algemeen wordt aangenomen dat in de banksector de budgetten nauwlettend worden gecontroleerd.
Volgende figuur geeft een beeld van hoeveel budget wordt toegewezen aan elke sprint en hoeveel er ook
daadwerkelijk werd gebruikt. Aangezien dit een snapshot is van het budget tot aan de vijfde sprint,
kunnen we in de rode grafiek zien dat tot nu toe ongeveer 60% van het budget is opgebruikt.
85
Figuur 42: Controle van het budget PARIS
Een laatste KPI dat wordt gemeten is de business capacity. De blauwe grafiek geeft weer wat de
initiele planning was. De veranderingen aan deze planning worden weergegeven door de oranje grafiek
en de rode grafiek toont de capaciteit die in werkelijkheid voorhanden is.
Figuur 43: Business capacity PARIS
86
3.4.2.2 Kritische blik
Zoals we bij ING gezien hebben is het zeer belangrijk dat Agile gelinkt is aan de strategie. Het bedrijf
moet de overgang willen maken en moet ervoor zorgen dat de druk niet te hoog is. Het team moet op
een minder gecontroleerde manier haar werk kunnen doen en minder tijd moet besteed worden aan
het rapporteren. Bij KBC hebben we echter wel gezien dat een vorm van controle ook wel belangrijk
kan zijn. Het team moet kunnen verantwoorden waarom de snelheid op sommige momenten minder
hoog is en bijgevolg moet deze oorzaak aangepakt worden. Budgetten zijn altijd belangrijk en moeten
ook hier onder controle worden gehouden. Als laatste KPI werd gewezen op de capaciteit. Gedurende
sommige sprints ligt de capaciteit gevoelig lager dan gepland. Dit is echter slechts een richtlijn. De
capaciteit wordt meer gebruikt om de actuele problemen op te lossen door snelheden tussen sprints te
vergelijken.
Verder merken we op dat KBC en BNP Paribas de Agile-methodiek voor projecten gebruikt die zich
situeren op het departementsniveau, terwijl het bij ING de bedoeling is om de volledige bedrijfscultuur
mee te nemen in het Agile verhaal. Om dit te verwezenlijken, moet worden gebruikgemaakt van een
framework dat het operationele niveau afstemt op de strategie. Dit verklaart het verschil in aanpak
tussen ING en de andere twee banken.
3.5 Projecten in de Logistieke sector
3.5.1 DHL
3.5.1.1 Projectaanpak
DHL werkt op vlak van projectmanagement met een methodologie die in-house ontwikkeld werd. De
gelijkenissen met PMBOK zijn echter groot. De methode wordt DePICT12 genoemd. Aangezien
we al uitvoerig geschreven hebben over de PMBOK lijkt het onnodig om data met betrekking tot
een van hun projecten in dit werk op te nemen. De DePict methode werkt met vijf grote stappen.
Define, Plan, Implement, Control en Transition houden net hetzelfde in als de vijf procesgroepen in het
PMBOK. DHL gebruikt het zogenaamde Project Workbook om het grootste deel van de informatie
met betrekking tot het project in bij te houden. Onderstaande figuur geeft een overzicht van de
verschillende onderdelen in deze template.
12Een overzicht van de methode wordt gegeven in Bijlage IV
87
Figuur 44: DHL Project Workbook
Net zoals de PMBOK wordt in de eerste fase een Project Charter opgesteld op basis waarvan het
project verder geleid zal worden. In deze Define fase wordt een groot deel van de functionaliteiten
van het bovenstaande workbook gebruikt. Voor de planning van start gaat, moeten alle requirements
duidelijk gedefinieerd zijn. Voor het vastleggen van de requirements uit gesprekken met de klant,
worden bij DHL verschillende tools gebruikt. Specifiek voor IT-projecten maakt men gebruik van een
IT Business Requirements Document dat in een eerste deel de huidige processen en problemen in kaart
brengt, waarna vervolgens in een tweede deel de oplossingen onder vorm van functionaliteiten worden
onderzocht en voorgesteld. Dit tweede deel maakt dan de opdeling tussen functionele requirements,
niet functionele requirements en constraints. Een andere tool die word gebruikt gedurende het project
is de Project Resources Tool. Deze tool bestaat uit de Resource Map en de Contact/stakeholder list.
De Resource Map is een hulpmiddel voor de project manager om de verschillende resources toe te
wijzen aan de verschillende rollen die werden gedefinieerd in het project. Voor de verschillende rollen
wordt opgesteld wat hun verantwoordelijkheid is en welke resource de rol zal invullen van de zijde van
DHL en van de klant.
In de volgende fase, de planning, wordt van start gegaan met de Project Organization. Dit houdt in
88
dat een meer gedetailleerde weergave van de stakeholders wordt gemaakt. De project manager moet
een aanvraag voor resources indienen bij de functionele manager, de directe overste van de gevraagde
resources. Wanneer deze resources niet beschikbaar zijn, moet de functionele manager instaan voor
het zoeken naar nieuwe resources die dan worden voorgesteld aan de project manager. Deze heeft
dan de autoriteit om te beslissen of de resources voldoen aan zijn specificaties en of ze geschikt zijn
voor het project. De infrastructuur wordt vastgelegd en de aanvaardbaarheidscriteria van de klant,
opgesteld in de Define fase, worden verfijnd. Daarna organiseert de project manager een kick-off
meeting met alle stakeholders. Vervolgens wordt een Work Breakdown Structure opgesteld die de
objectieven gaat vertalen in work packages, die ook in de project workbook worden bijgehouden.
Op basis van alle workpackages wordt het projectplan opgesteld. Er wordt dan gekeken naar de
effort en de tijd die nodig zijn om de verschillende activiteiten te voltooien. Met behulp hiervan
wordt dan een Critical Path Analyse uitgevoerd die een beeld geeft van de duurtijd die nodig is
om de langste rij aan afhankelijke activiteiten uit te voeren. Aan de hand van dit plan kan men
met zekerheid de benodigde resources bevestigen. Verder wordt ook een communicatieplan opgesteld.
Hierin wordt gekeken welke stakeholders de informatie nodig hebben, wanneer die ze nodig hebben
en hoe ze de informatie zullen bekomen. Het is ook belangrijk om rekening te houden met kwaliteit,
de aankopen en het budget. Deze zaken werden al aangehaald in de Project Charter en krijgen hier
meer aandacht met betrekking tot een gedetailleerde planning. Wanneer deze activiteiten achter de
rug zijn, wordt gekeken naar het risico. Dit is een grote stap. Hier wordt gewerkt in vier grote
fasen. Eerst worden de risico’s geıdentificeerd. Vervolgens worden ze geanalyseerd, gekwalificeerd en
gekwantificeerd. Dit houdt in dat gekeken wordt naar de kans waarmee ze kunnen voorkomen en de
impact die ze kunnen hebben op de planning. Vervolgens wordt rekening gehouden met dit risico
in de planning. Mitigation en Contingency plannen worden opgesteld. Een mitigation plan is een
documentatie van de technieken en de acties die zullen gebruikt worden om het risico te reduceren en
te controleren. Een zeker tolerantieniveau wordt vooropgesteld. Wanneer dit niveau niet gehaald kan
worden, zal worden overgegaan naar de contingency planning. Een contingency plan is een backup
plan of houdt acties in die genomen moeten worden wanneer zaken beginnen fout te lopen. Als laatste
stap is er dan nog het monitoren en de controle over deze risico’s. De risico’s worden bijgehouden
in de Risk Log van zodra een Risk Assessement formulier werd ingevuld. Dit is reeds gebeurd in de
eerste stap. Deze risk log kan ten allen tijde worden aangevuld en wordt op regelmatige tijdstippen
gecontroleerd door de project manager.
Een volgende fase is de implementatiefase. Het project wordt volgens plan uitgevoerd. Ook hier
89
worden bijkomende risico’s geıdentificeerd. Dit wordt gedaan door gebruik te maken van de Failure
Mode and Effect Analysis. Het is een tool die de effecten van fouten op het project gaat onderzoeken.
Naast deze FMEA wordt ook nog gebruik gemaakt van de Go-Live Readiness Checklist waarmee
gekeken wordt naar de voortgang van het project rekening houdend met de nakende deadline.
De controlefase maakt gebruik van iteraties om de voortgang van het project af te wegen tegenover
het projectplan. Er wordt gebruik gemaakt van statusrapporten om de stakeholders op de hoogte
te houden van de ontwikkelingen. Een eerste tool om de controle te voeren is de Issues log. Hierin
worden de problemen gedefinieerd en wordt gekeken welk gevaar het kan opleveren voor het project.
Een andere tool is deze voor het managen van de change requests. Wanneer een functionaliteit niet
overeenkomt met die van de klant of de functionaliteit niet aanwezig is, wordt een change request
formulier ingevuld om dit aan de klant te rapporteren. Deze change requests worden bijgehouden in
de Change Control log. Er wordt gekeken wat de impact van deze change zal zijn op de tijd en het
budget. Het kan ook zijn dat de change een impact zal hebben op de werking van het product in
de operationele fase. Wanneer geld kan bespaard worden in de operationele fase door nu een extra
investering door te voeren, kan dit een gunstige ingreep zijn. Daarom moet telkens ook de impact
bekeken worden op de business case.
In de laatste fase, de transition, wordt het proces volgens een formele procedure afgesloten. De geleerde
lessen zijn hier een belangrijk aspect om mee te nemen naar de toekomst. Een Project Closure and
Acceptance Form is hier een andere belangrijke tool van de klant of sponsor om te evalueren of het
eindproduct voldoet aan de aanvaardbaarheidscriteria. Als laatste wordt een Project Final Report
opgesteld door de project manager dat een samenvatting is van de bovenstaande stappen die doorlopen
werden doorheen het project.
Typisch is er ook nog een post-project evaluatie tool die de project manager in staat stelt om de leden
van het team te evalueren op de geleverde prestaties. De teamleden moeten dan zelf ook het gedrag in
team evalueren. Verder wordt ook de sponsor geevalueerd door de project manager en de teamleden.
Als laatste krijgt de project manager ook nog een beoordeling.
90
3.5.1.2 Kritische blik
Deze aanpak is een vrijwel identieke toepassing van de PMBOK. Het grote nadeel hier zijn de change
requests. De afdeling waarbinnen wij de projectaanpak hebben bekeken is de afdeling projectmanage-
ment voor supply chain projecten. Het gaat hier om de optimalisatie van stock levels en het leveren
van een geıntegreerde aanpak van het warehousing systeem van de klant en de volgende schakel in de
supply chain keten.
De personen waarmee wij in dit departement hebben gepraat, staan vrij afzijdig tegenover Agile
omwille van de testrapportering. In dit type projecten is het belangrijk dat kan aangetoond worden
aan de klant dat het product werkt. Dit wordt hier intensief gedaan door het ontwikkelen van een
testomgeving. Ze zien verder ook niet echt de noodzaak van het overschakelen naar Agile binnen hun
departement omdat over het algemeen realistisch wordt gereageerd op change requests bij de klanten.
In ons opzicht zou het wel mogelijk zijn om een gecombineerde aanpak toe te passen. Het werken met
iteraties toegepast in de klassieke methode kan een win-win situatie opleveren voor DHL en de klant.
3.6 Projecten in de auto-industrie
3.6.1 Toyota Motor
Toyota Motor staat bekend als wereldspeler in de automotive sector. Daarnaast wordt het dikwijls
aangehaald als schoolvoorbeeld voor Lean manufacturing. Het Toyota Production System (TPS)
ligt immers aan de basis van Lean. Toyota kent een heel sterke cultuur die staat voor efficientie,
samenwerken en continue verbetering. Volgens Tanaka en Tanner(2007) wordt dit ook geıncorporeerd
in hun methodologie voor projectmanagement. Zo maakt Toyota gebruik van verschillende tools.
Een van die tools is Oobeya13, wat grote ruimte betekent. De Oobeya room werd ontwikkeld door
Horikiri, et al.(2008) en maakt gebruik van een duidelijke weergave van objectieven en visualisatie
van het werk om zo de samenwerking te stimuleren en de probleemoplossing te vereenvoudigen. Voor
de visualisatie van de objectieven en de verwachte uitkomsten wordt ook gebruik gemaakt van een
Barashi board14. Dit beschrijft de objectieven op lange termijn, de teamstructuur, de regels, de acties,
de KPI’s enzovoort15. Het zorgt ervoor dat deze zaken duidelijk worden voorgesteld zodat het team
de voeling met de beslissingen op strategisch niveau niet uit het oog zou verliezen. De projectleider
13Visualisatie van de Oobeya room in Bijlage I.14Visualisatie van het Barashi Board in Bijlage II.15De tools die gebruikt worden in Barashi om de performance van het team te meten, worden voorgesteld in Bijlage
III
91
stelt de verschillende objectieven duidelijk voor, waarna elk team het deel van het project waarop het
actief is, moet opdelen in kleinere objectieven en uiteindelijk activiteiten. Het barashi board heeft
drie grote voordelen. Een eerste is dat het zorgt voor structuur door het team haar eigen barashi
board te laten construeren. Op die manier gaat het om met de objectieven en weet het wat van hen
wordt verwacht. Het zorgt er ook voor dat de communicatie beter is. Elke team leader begrijpt de
aanpak die door de andere team leaders wordt gebruikt. Ten slotte zorgt het ook voor een krachtige
elevator speech. Dankzij de visuele voorstelling, kunnen de teamleden hun werkwijze en taken in een
korte periode van ongeveer drie minuten uitleggen aan personen die niet betrokken zijn bij het project
(Tanaka et al., 2007).
We zien dus dat Toyota haar cultuur van Lean doortrekt naar haar verschillende departementen. Wij
hebben een bezoek gebracht aan het Toyota Material Handling Europe (TMHE) in Brussel waar al
snel duidelijk werd dat deze tools hun intrede nog niet hebben gemaakt. Ze passen vooral klassiek
projectmanagement volgens de PMBOK toe, maar we zien dat ze hier en daar toch wel voeling hebben
met enkele Lean principes en deze, zonder het bewust te weten, gaan toepassen in hun manier voor
projectmanagement. Binnen TMHE ligt de focus vooral op de scope, de kwaliteit en de tijd. Het
budget wordt niet nauwkeurig bijgehouden.
Door middel van ’Hoshin Kanri’ zorgt Toyota ervoor dat de juiste projecten worden geselecteerd.
‘Hoshin Kanri’ is een methode die ervoor zorgt dat de acties van het middenmanagement en het werk
van de werknemers in lijn liggen met de strategie. Dit vermindert de verspilling die afkomstig is van
inconsistente richting en slechte communicatie. Enkel de projecten die gefilterd werden met behulp
van Hoshin Kanri maken kans om aangevat te worden.
3.6.1.1 Projectaanpak
Toyota maakt voor de opvolging van zijn projecten gebruikt van Excellence Project Management
(XLPM). XLPM werd ontwikkeld door Semcon16 en focust op de ondersteuning, hulpmiddelen, sja-
blonen en modellen voor Project Management en Portfolio Management. De methode is de uitloper
van PROPS, dat werd ontwikkeld binnen Ericsson maar intussen volledig werd vervangen door XLPM.
Tijdens de eerste fase, ‘Analyse’, wordt er een ‘Business need’ uitgesproken. Vervolgens is er een kick
off event waar een tijdsplan en HR plan wordt opgesteld. Hier bepaalt men ook wie welke training
moet volgen indien nodig. Het volledige pre-study rapport wordt vaak in Powerpoint uitgeschreven.
16Een bedrijf met hoofdzetel in Zweden dat erop gericht is om bedrijven bij te staan in de ontwikkeling van producten.
- www.semcon.com
92
Wendy Verborgh vertelde ons dat in 80% van het projectfalen niets op voorhand werd uitgeschreven.
Om de analyse fase af te sluiten moet men het project voorleggen aan de hoofdkantoren in Japan
ter goedkeuring. De verschillende fasen en activiteiten worden gescheiden door tolgates waar beslist
wordt of overgegaan wordt naar de volgende fase of activiteit. In deze tolgates worden dan ook meestal
feasibility studies uitgevoerd.
Gedurende de planningsfase worden gedetailleerde GANTT-charts gemaakt in Excel. Omwille van
licentieverplichtingen maakt Toyota Handling geen gebruik van meer gesofisticeerde programma’s zoals
Primavera, MS Projects,... De eigen ontwikkelde tool scoort echter wel slecht op communicatie en
wordt daarom aangevuld met een lijst van stakeholders. Om te beslissen welke mensen je in het
projectteam wenst op te nemen, worden powermaps opgesteld die de relaties tussen de verschillende
mensen weergeven. Wanneer de project manager een beslissing neemt, wordt dit opgenomen in een
resource allocation contract. Verder merkten we op dat de voorbije twee fasen het meeste tijd in beslag
nemen, net zoals bij klassiek projectmanagement het geval is.
Gedurende de derde fase, de executiefase, geven de steering commitees door middel van meetings een
algemeen overzicht. Verder kan er door de klant ook een change request worden gedaan. In deze fase
worden de activiteiten ook gecontroleerd. Verschillende acties, problemen, risico’s worden opgenomen
in een centraal document. Wanneer een teamlid een bepaalde actie moet ondernemen, krijgt deze een
geel vlagje naast zijn naam dat verwijst naar de bepaalde actie. Als de persoon de actie na drie weken
nog steeds niet heeft uitgevoerd, wordt het gele vlagje vervangen door een rood vlagje, wat wijst op
een groot risico. Deze acties worden gerapporteerd aan het hoger management. Het mag dus duidelijk
zijn dat niemand wilt dat een rood vlagje naast zijn naam komt te staan. Volgens Verborgh is dit
de beste methode om zaken gedaan te krijgen van mensen. De project manager moet dus een goed
overzicht behouden van de verschillende acties en moet in staat zijn om de verschillende graden van
belangrijkheid aan de acties te geven.
Bij het afsluiten van het project wordt een finaal rapport gemaakt met de geleerde lessen uit het
project. Daarna wordt er in team gestemd op drie zaken die nog verbeterd kunnen worden. Hierin is
de link met het lerende aspect van Lean wel duidelijk voelbaar. Tot slot wordt er ook een overzicht
gemaakt van welke drie lessen geleerd werden.
93
3.6.1.2 Kritische blik
Alvorens een bezoek gebracht te hebben aan Toyota, hadden we grootse verwachtingen op vlak van
Lean Project Management. Eenmaal in gesprek met Wendy Verborgh bleek echter dat principes als
Oobeya en Barashi niet worden toegepast binnen het TMHE. Het is opmerkelijk dat er binnen de
cultuur van dergelijke wereldmacht grote verschillen bestaan in werkwijze naargelang de geografische
locatie. Verborgh vertelde ons dat het in de cultuur van TMHE moeilijk is om aan projectmanagement
te gaan doen omdat er weinig steun komt van de oversten. Vele projecten worden aangevat zonder
duidelijke formulering van het probleem. Project managers als Verborgh doen dan wel hun uiterste
best om alles zo goed mogelijk volgens de werkwijze van de PMBOK te laten verlopen. De technieken
die zij toepassen en die we in vorige sectie kort hebben toegelicht, voldoen dan zeker aan de basiscriteria
voor het voeren van projectmanagement. Om dit te verwezenlijken hebben ze zich in eerste instantie
gericht op het volgen van de PMBOK lifecycle.
94
4 Algemeen besluit
In de conclusies van deze thesis zullen we eerst bespreken wat in de aan bod gekomen sectoren gaande
is op vlak van projectmanagement. Vervolgens zal een beschrijving worden gemaakt van wat volgens
ons de toekomst zal brengen binnen dit vakgebied.
Om van start te gaan, kunnen we zeggen dat de software-ontwikkeling en de banksector twee sectoren
zijn die heel vooruitstrevend zijn op vlak van projectmanagement. In deze sectoren is Agile nu al
de meer de regel dan de uitzondering. In de toekomst zullen deze sectoren in Vlaanderen de Agile-
methodieken nog meer proberen incorporeren en deze trachten te laten uitstijgen naar projecten op
bedrijfsniveau. De huidige problemen die de bedrijven ervaren met bepaalde Agile methodieken zoals
Scrum op het strategische niveau zullen moeten worden bekeken en kan ertoe leiden dat ze beslissen
om over te schakelen naar een andere methodiek of ze proberen om Scrum aan te passen aan hun
noden. Aangezien Agile een prescriptieve methodiek is, is het mogelijk om de principes aan te passen
aan de cultuur van het bedrijf, hoewel deze werkwijze meestal niet van een leien dakje loopt.
Een sector die minder vooruitstrevend is, maar wordt gekenmerkt door organisaties met sterke culturen
die specialisatie en in-house ontwikkeling hoog in het vaandel dragen, is de automobielsector. Deze
bedrijven zijn zodanig groot dat ze kunnen investeren in de ontwikkeling van eigen methodes voor
projectmanagement en zich hier ook aan vasthouden omwille van hun bewezen nut in het verleden. Ze
willen voorkomen dat eerder gevoerd werk tot niets zou dienen. Dit hebben we in beide casestudies in
deze sector gemerkt. Recente methodieken zijn daar minder bekend door een sterke focus op de eigen
methodes.
In de constructiesector is het moeilijk om de overschakeling naar nieuwe methodieken te maken omdat
de bouw in de praktijk dikwijls gepaard gaat met onderaannemers en het constructieproces lineair van
aard is. De eerste fasen kunnen wel met Agile worden uitgevoerd om de requirements te definieren
en de vergunningen op te stellen maar eens overgegaan wordt tot de constructie is dit moeilijk. Dan
zou eventueel kunnen gebruik gemaakt worden van Lean maar dit kent omwille van een kwetsbaar
tijdsplan dan ook weer grote nadelen. Bij Agile is het vooral het probleem dat er te veel verschillende
partijen betrokken zijn bij de uitvoering en het constructieproces ook lineair van aard is. Lean is vooral
toepasbaar binnen een statische omgeving en kan dus ook niet toegepast worden in de eerste fasen van
een constructieproject waar veel onzekerheid aanwezig is. De constructiesector biedt daarom weinig
toekomstperspectieven voor het voeren van projectmanagement volgens een van deze technieken. De
waterfallmethode biedt hier duidelijke voordelen.
95
Voor de overheidsprojecten is vooral de kwaliteit belangrijk. Veel overheidsbedrijven, zoals BPost,
maken vooral voor de ontwikkeling van software gebruik van Agile. Aangezien het gebruiksgemak en
de kwaliteit centraal staan in overheidsprojecten, kan Agile een goeie methodiek zijn voor project-
management binnen deze sector. De producten kunnen dan in overleg met de verschillende partijen
goed afgestemd worden op de veranderende noden van de eindgebruiker. Het type project is hier dan
ook weer belangrijk. Voor IT-projecten is het geen probleem om aan Agile te doen maar als het gaat
om een constructieproject zoals in een van bovenstaande casestudies, zal dit evenwel minder tot de
mogelijkheden behoren.
In de logistieke sector gebruiken de bedrijven al Agile voor in-house applicaties en software. Voor de
projecten samen met klanten ligt dergelijke overgang nog moeilijk gezien hun vraag naar uitgebreide
testrapporten. In Agile wordt voorgeschreven om zo weinig mogelijk documentatie bij te houden. Dit
zorgt ervoor dat er met angst gekeken wordt naar dergelijke methodiek. De huidige systemen geven
de mogelijkheid om intensief te testen dus wordt verkozen om hiermee verder te gaan.
Gezien de tekortkomingen van individuele methodieken, zal de toekomst van projectmanagement vol-
gens ons gestuurd worden door een meer gecombineerde aanpak. Wanneer bedrijven geınteresseerd zijn
in een iteratieve aanpak zoals Agile maar toch meer controle willen behouden, kan een gecombineerde
methodiek van klassiek projectmanagement en Agile mogelijkheden bieden. De functionaliteiten in de
sprints kunnen dan meer centraal worden gepland maar het product kan wel nog steeds op een itera-
tieve manier worden opgeleverd en er kan nog geprofiteerd worden van de voordelen met betrekking
tot het incorporeren van de feedback van de klant of gebruiker in het product.
Wanneer een bedrijf toch aan Agile wilt doen maar problemen heeft met het gebrek aan strategische
koppeling van het project, kan het gebruikmaken van een framework zoals SAFe dat een brug slaat
tussen Lean en Agile. Dergelijke aanpak kan de problemen die gepaard gaan met een culturele overgang
gedeeltelijk oplossen. Vooral in grote bedrijven kan dit een oplossing bieden. In kleinere bedrijven
waar rechtstreeks contact is tussen het management en het projectteam, kan een eenvoudigere aanpak
als Scrum worden gebruikt. In bedrijven met verschillende culturele lagen, waar rapportering naar
het management in verschillende stappen gebeurt, kan het werken met Scrum problemen opleveren.
Dit kan opgelost worden door een methodiek te gebruiken die ook strategisch goed ontwikkeld is.
96
5 Bibliografie
Ambler, S. W. (2009) Scaling agile software development through lean governance, Proceedings of Soft-
ware Development Governance SDG09 - ICSE’09 Workshop, Vancouver, Canada: IEEE Computer
Society.
Ballard, G. & Howell, G.A. (2003). Lean Project Management. Building Research & Information,
31(1), 1-15
Ballard, G. & Howell, G.A. (2003). Lean Project Management. Building Research & Information,
31(2), 119-133
Chatfield, C.S. & Johnson, T.D. (2003). Microsoft Office Project 2003 Step by Step, 476
Cobb, C.G (2011). Agile Project Management, Balancing Control and Agility.
Collyer, S., & Warren, C.M. (2009). Project management approaches for dynamic environments. In-
ternational Journal of Project Management, 27 (4) , 335-364.
Cusumano, M.A. (1994). The Limits of ”Lean”. , Sloan Management Review, 35(4), 27-32
Demir, S. T., & Bryde, D.J., & Sertyesilisik, B. (2014). Introducing agilean to construction project
management. The Journal of Modern Project Management, 28-38.
Denyer, D., Kutch, E., & Lee-Kelley, E. (2011). Exploring reliability in information systems program-
mes.
Derby, E. & Larsen, D. (2005). Agile Retrospectives, Making Good Teams Great!
Drucker, P. (1999). Management Challenges for the 21st Century, Harper Business, 33.
Fernandez, D.J, & Fernandez, J.D.(2008). Agile Project Management- Agilism versus traditional ap-
97
proaches. Journal of Computer Information Systems, Winter 2008-2009, 10-17.
Goldratt, E.M. (1997). Critical Chain.
Guytingco, A.(2015). The Lean Manufacturing House. Integrated product & services inc.
Hass, K. (2007). The Blending of Traditional and Agile Project Management. PM World
Hofstede, G.H. (2005). Cultures and organizations: software of the mind.
Horikiri, T. , Kieffer, D. & Tanaka, T. (2008). Oobeya-Next Generation of Fast in Product Develop-
ment.
Hossain, E. , Babar, M.A. & Paik,H. (2009). Using Scrum in Global Software Development: A Sys-
tematic Literature Review.Fourth IEEE International Conference on Global Software Engineering ,
175-184.
Karlesky, M. , & Voord, M.V. (2008). Agile Project Management (or, Burning your Gantt Charts).
Embedded Systems Conference (pp. 1-8). Boston Atomic Object & X-Rite.
Koskela, L. (2000). An Exploration Towards a Production Theory and its Application to Construc-
tion. VTT Publications, 408
Leffingwell, D. (2010). Agile Software Requirements Lean requirements practices for teams, programs
and the enterprise.
Leido, P. (2014). Lean & Agile: Project Management.
Livari, J. , & Livari, N. (2011). The relationship between organizational culture and the development
of agile methods. Information and Software Technology 53, 509-520
MacCormack, A. (2003). Creating a Fast and Flexible Process: Research Suggests Keys to Success.
98
www.roundtable.com.
Maximilien, E. M. , & Williams, L. (2003). Assessing Test-Driven Development at IBM
Mossman, A. , Ballard, G. , & Pasquire, C. (2010). Lean Project Delivery innovation in integrated
design & deliver. Architectural Engineering and Design Management.
Owen, R. , Koskela, L., Henrich, G., & Codinhoto, R. (2006). Is Agile Project Management applicable
to construction?
Pikkarainen, M., & Passoja, U. (2005). An Approach for Assessing Suitability of Agile Solutions: A
Case Study.
Poppendieck, M., Poppendieck, T. (2003) Lean software development: an agile toolkit
Poppendieck, M., & Poppendieck, T. (2009). Leading Lean Software Development: Results are not
the point.
Quinn, R.E. & Rohrbaugh, J. A (1983) A spatial model of effectiveness criteria: towards acompeting
values approach to organizational analysis. Management Science 29, 363-377
Schilling, M. (2013) Strategic Management of Technological Innovation
Schwaber, K. (2004) Agile Project Management with Scrum
Shen, L. & Chua, D.K.H. (2008). An Investigation of Critical Chain and Lean Project Scheduling.
Stoterau, J. (2012). Lean Project Management. sqs.com.
Tanaka, T. & Tanner, S. (2009). The Visualization of Purpose: Quickening the Pace of Executive
Achievement Through the Visualization of Purpose. The Lean Enterprise Academy.
99
Vanhoucke, M. (2013). Project Management with Dynamic Scheduling
Wang, X. , Conboy, K. & Cawley, O. (2011) Leagile Software Development: An Experience Report
Analysis of the Applicationof Lean Approaches in Agile Software Development
Wildeman, R.M. (2002). Comparing PRINCE2 with PMBOK
Wysocki, R.K. (2003). Effective Project Management: Traditional, Agile, Extreme.
100
6 Bijlagen
Bijlage I Oobeya room Toyota
Figuur 45: Oobeya room Toyota
Bijlage II Barashi Board Toyota
Figuur 46: Barashi Board Toyota
I
Bijlage III Barashi Board Tools Toyota
Figuur 47: Barashi Board Tools Toyota
Bijlage IV DePICT Framework DHL
II
Fig
uu
r48
:O
verz
icht
van
de
DeP
ict
Pro
ject
Man
agem
ent
aan
pak
III
Recommended