ACADEMIEJAAR 2015 2016 Een vergelijkende studie tussen het...

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.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.2 Kritische blik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.3 Overheidsprojecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3.1 Constructie project Station Gent Sint Pieters . . . . . . . . . . . . . . . . . . . 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.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 producten 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


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


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


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.


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.


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


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


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


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


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


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.


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


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

ACADEMIEJAAR 2015 2016 Een vergelijkende studie tussen het...

Documents

Transcript of ACADEMIEJAAR 2015 2016 Een vergelijkende studie tussen het...