
17 minute read
Hoofdstuk 19 Ontwikkelt elk bedrijf agile of volgens de waterfall-methode? #tussenvormen
by VAN IN
1 Inleiding en leerdoel
De manieren waarop een project kan worden uitgevoerd zijn in theorie terug te brengen tot een van de methodes die in dit boek worden beschreven. Binnen een bedrijfscontext merken we echter dat het veelal – om goede redenen – niet evident is één en slechts één methode toe te passen.
In dit hoofdstuk willen we die pragmatische aanpak duiden. We zijn overtuigd dat de voordelen van agile werkmethodes zeer duidelijk zijn en meestal tot een positief project kunnen leiden. Maar de gedachte dat agile werkmethodes alle projectzorgen oplossen komt niet overeen met de realiteit. Naast het geven van een beoordelingskader willen we ook aan de hand van twee cases toelichten waarom het relevant kan zijn om een tussenvorm te kiezen of te gaan voor een gemengde vorm.
Op het einde van dit hoofdstuk: … kan ik de redenen benoemen die meespelen in de keuze voor een uitvoeringsmethode; ben ik in staat om voor mijn project in een bedrijfscontext te beoordelen welke methode of tussenvorm van methodes de kans verhoogt dat mijn project succesvol zal zijn.
2 Agile werken in de praktijk
Hoewel iteratieve en agile strategieën zoals SCRUM vandaag als de referentie worden beschouwd, is het belangrijk altijd de vraag te blijven stellen welke strategie in een bepaald project de beste is. In de huidige projectcultuur is er geen discussie meer over het feit dat feedback van klanten en gebruikers noodzakelijk is voor een kwalitatieve oplevering van een digitale oplossing. Voor velen staat het verkrijgen en integreren van de feedback automatisch gelijk aan een implementatie op basis van SCRUM. Toch zijn er nog altijd projecten waar een waterfall-methode de geprefereerde methode kan zijn. Projecten waarbij de nood vooral geïnitieerd wordt uit legale wijzigingen, kunnen veelal perfect worden opgeleverd vanuit de waterfall-methode: de vereisten zijn zeer goed gekend aan het begin van het project en zijn (bijna) niet onderhevig aan wijzigingen vanuit de klant. Voor dat type projecten kan er dus zonder problemen met een minder iteratieve strategie worden gewerkt.
In de volgende paragrafen belichten we enkele bepalende factoren die de keuze kunnen beïnvloeden.
2.1 Factor 1: de oplossing
De volgende figuur geeft weer in welke situaties we het best kiezen voor agile ontwikkelen. Op de verticale as staat de complexiteit van de vereisten en de context waarin het project zich bevindt: is iedereen het eens over wat er moet gebeuren of is er door de complexiteit van de omgeving heel veel onduidelijkheid en onenigheid tussen alle betrokkenen? Op de horizontale as staat de zekerheid: hoe zeker is men van de technologie die moet worden gebruikt, hoe zeker is het verwachte eindresultaat? Door de twee parameters te schalen, krijg je een idee wanneer agile development kan worden toegepast.
Als een project als complex of complicated wordt beschreven, is agile de beste keuze. Als een project echter in het gebied ‘simple’ valt, kan een waterfall-methode een perfect te verantwoorden keuze zijn. Projecten die in een anarchistische situatie verkeren, worden beter niet opgestart. Er zal in dat geval eerst een voortraject moeten worden voorzien om de complexiteit of onzekerheid te verminderen. Een prototype is in dat geval een mogelijke oplossing.
Figuur 1 Wanneer kies je er het best voor om agile te ontwikkelen?
Far from agreement complicated complex anarchy simple complicated
Close to certainty
Bron: Strategic Management and Organizational Dynamics, Ralph D. Stacey.
2.2 Factor 2: de mensen
Far from certainty
Hoewel SCRUM heel veel voordelen biedt, vraagt de methode veel van de teamleden: korte ontwikkelcycli, veel feedback verwerken, flexibel omgaan met vereisten en eindgebruikers, multidisciplinariteit … We zien dan ook dat grote bedrijven minder en minder kiezen voor de SCRUMmethodologie omdat de organisatie niet in staat is de flexibiliteit te leveren die werken met SCRUM van eindgebruikers vraagt. Het is één ding om het IT-departement agile te structureren, maar het is veelal minder eenvoudig om ook de businessprocessen op korte termijn te herorganiseren. Dikwijls zien we bij die bedrijven dus een combinatie waarbij IT-teams wel volgens de SCRUM-methodologie ontwikkelen en unit-testen, maar waarbij de business nog eerder op een waterfall-manier specificaties aanbrengt en acceptatietesten uitvoert.
Agile methodes zoals SCRUM zullen ook maar 100% effect hebben als ze goed worden uitgevoerd. Dat betekent ook dat de teams voldoende kennis moeten hebben over de technieken. Daarmee bedoelen we uiteraard praktische kennis en ervaring. We zien dikwijls dat daar het schoentje wringt en dat slechts enkele facetten worden toegepast. Zo merken we regelmatig dat binnen projecten wel een daily scrum (of stand-up) wordt gehouden, maar dat men de principes rond sprintplanning of sprintretro niet toepast. Daarmee willen we dus vooral wijzen op het belang van kennis bij de mensen betrokken bij de uitvoering maar ook op het belang van de potentie om binnen het bedrijf de andere facetten van de methode georganiseerd te krijgen. Daar kan de grootste moeilijkheid zitten, omdat die manier van werken en organiseren mogelijk niet aansluit bij hoe men voorheen of buiten het project werkt.
2.3 Factor 3: de snelheid
We hebben al elders in dit boek gesteld dat de snelheid van uitvoering, maar ook de snelheid waarmee tastbaar resultaat wordt opgeleverd voor de klant (of de business), een van de grootste troeven is van agile methodes. Zowel voor 100% IT-projecten als voor gemengde projecten, krijgt de business het gevoel dat de snelheid waarmee de organisatie wordt geholpen en verbeterd, veel hoger ligt. “We verbeteren of innoveren aan een hoger tempo!” Dat is meestal de feedback die je hoort zodra een bedrijf agile methodes correct begint toe te passen.
Die vaststelling bevestigen we helemaal vanuit onze praktijkervaring. Echter merken we dat de snelheid om tastbaar resultaat te zien, wel eens begint te primeren op cruciale elementen die maken dat een project al dan niet succesvol is. Daarbij denken we aan volledigheid van het (werkend) product, integratie van de oplossing in het volledige landschap, begeleiding van gebruikers (change management), documentatie, roll-out naar de rest van de organisatie na een succesvolle piloot enzovoort. Binnen een volwaardig agile traject passen die verwachtingen uiteraard wel, alleen krijgen die in veel bedrijven echter niet de juiste focus of het juiste gewicht en worden daarom niet – of niet voldoende – opgenomen als scope.
Het is dus immer belangrijk om je af te vragen welke strategie de meest zinvolle is, en niet automatisch te kiezen voor die strategie die op dat moment de meest gangbare is. In de volgende paragrafen zullen we twee concrete cases bespreken waarbij wordt uitgelegd welke uitvoeringsmethode werd gekozen en waarom. Die concrete cases zijn reallifeprojecten maar werden wel geanonimiseerd.
3 Case 1: Optimalisatie onboarding
3.1 Projectvraag
Een servicebedrijf steunt op een beperkt IT-team. Op jaarbasis zijn er ongeveer een honderdtal starters binnen de onderneming. Hoewel die starters verspreid zitten in de ganse organisatie en dus in andere departementen, zijn de opstartactiviteiten m.b.t. IT erg gelijklopend. Binnen het team is er consensus dat de activiteiten meer gestroomlijnd en ook meer geautomatiseerd kunnen worden. Uit een survey bij de recente starters werd ook geleerd op welke punten het proces niet 100% perfect is. De optimalisatie van de onboarding (vanuit IT-oogpunt) – dus enerzijds de verbetering van het proces en anderzijds de automatisatie – wordt gebundeld in de scope van het project.
3.2 Oplossing
Om dat proces te ondersteunen gebruikt het IT-team al een servicerequestplatform dat workflows ondersteunt. Drie jaar voor de start van het project werd de bestaande flow al gedocumenteerd en voor 50% geautomatiseerd op basis van de toen gekende behoeftes en grootste problemen.
Er wordt gekozen om binnen het bestaande platform te blijven werken, maar het onboardingproces wordt wel eerst op een wit blad opnieuw uitgetekend. Aansluitend wordt dat herziene proces in een (geautomatiseerde) workflow geconfigureerd binnen het servicerequestplatform.
Het einddoel is dat het IT-team amper nog manuele taken behoudt voor die flow zodra de personeelsdienst de nieuwkomer aanmeldt en aangeeft tot welke afdeling deze persoon zal behoren en welke functie die zal uitvoeren. Uiteraard zullen de nodige notificaties worden voorzien, eveneens richting de leidinggevende, de personeelsdienst en eventuele externe partners (bv. bestelling smartphone en activatie sim-kaart). Het eindproduct moet ervoor zorgen dat in 90% van de flows alleen de servicedeskoperator de flow dient op te volgen en de andere experten binnen het IT-team gevrijwaard blijven van (administratieve) taken.
Voor dat project werd een tijdshorizon van 6 maanden voorzien omdat enerzijds binnen het IT-team slecht één expert-analist gedeeltelijk kon worden toegewezen en anderzijds de leidinggevende van het IT-team als productowner slechts 4 uur per week met focus kon werken op dat project.
3.3 Plan van aanpak
De onderneming is gebaat bij voortgang op haar verbeterprojecten en daarom wordt geopteerd om te werken in korte cycli van 1 week. Daarbij wordt per week een vast afstemmoment voorzien met als doelstellingen:
• review van geleverde werk (validatie);
• doorspreken / oplossen vastgestelde hordes of problemen;
• vastleggen focus volgende week, inclusief hoe de output er diende uit te zien (kladblad analyse; workflow analysedocument, configuratietest in platform, …).
In de uitvoering of werkorganisatie werden veel elementen van SCRUM-gebaseerd werken weerhouden. Wat waren de beweegredenen om die aanpak te volgen, waarbij tot op een zeker niveau wordt aangeleund bij een agile werkmethode? We doen de evaluatie in volgende tabel.
Tabel 1 Voorbeeld bepaling ontwikkelstrategie Case 1.
Factor
Oplossing
Mensen
Snelheid
Toelichting
De oplossing bestaat uit een grondige analyse, workflowdesign en workflowimplementatie met achterliggende scripts om het werk te automatiseren.
In die bedrijfscontext zijn vele applicaties betrokken, waarbij ook dient te worden beoordeeld welke toegangsrechten een nieuwe medewerker bijvoorbeeld nodig heeft in zijn nieuwe functie. De setup van die toegangsrechten gebeurt veelal niet automatisch en vraagt manuele tussenkomst van de applicatiebeheerder. We verwachten dan dus redelijk wat afstemming door de analyse heen omdat we een alomvattende oplossing vooropstellen, en eveneens een aanzienlijk testvolume om te verzekeren dat de informatie-uitwisseling via de workflow afdoende is (in twee richtingen, m.a.w. bij de request maar ook nadat de nodige set-up gebeurd is).
Ons assessment: complicated
Er zijn primair maar twee sleutelactoren die voldoende ervaren zijn in het onderwerp. Dat zal het project zeker helpen en verzekeren dat de juiste dingen kunnen gebeuren en worden besproken.
Beide personen hebben een (beperkte) praktische ervaring met SCRUM maar zijn wel voldoende vertrouwd met de basisprincipes om sprint-gedreven te kunnen werken en bijvoorbeeld wekelijks de voortgang te bespreken.
Op het moment van de uitvoering van het project was het bedrijf of de IT-afdeling nog niet 100% ingesteld op agile werken. Daarmee dienden we wel rekening te houden. Dat was vooral duidelijk bij de resourceplanning van de analist die dikwijls gevraagd werd voor andere, grotere (waterfall-gedreven) projecten, waardoor zijn beschikbaarheid nog meer onder druk kwam. In de ideale wereld was hij voor een periode van 3 maanden ‘vrijgemaakt’ om dat relatief kleine initiatief in één keer volledig af te werken.
Gezien de beperkte beschikbaarheid wensen we voldoende snel te kunnen werken om de capaciteit terug vrij te geven. Vanuit die beoordeling werd de sprintmethodiek aangehouden. De duur van 1 week was goed om voldoende focus te houden en rekening te kunnen houden in het ‘activeren’ van taken of topics voor de komende sprint (in het licht van bijvoorbeeld andere operationele taken die een impact hadden op de beschikbaarheid van de analist).
De eerste sprints richtten zich op analyse en het kunnen beoordelen van de complexiteit van de volgende stappen (realisatie). Vanuit de analyse werden ook de requirements (product backlog) verder verfijnd.
Werd hier de juiste manier van werken gekozen? Voortgaand op de resultaten is het antwoord zeker ‘ja’. De iteratieve manier van werken, met korte sprints van 1 week, heeft ertoe geleid dat op korte termijn zowel in de analyse als in de implementatie van de workflow tastbaar resultaat zichtbaar was. Dat was vooral mogelijk in deze omgeving omdat slechts een beperkt aantal mensen betrokken was en het project vooral werd gedragen door twee experts. Omdat het bij de start onduidelijk was hoe uitgebreid de verbetering zou zijn, was het een pluspunt om na elke analyse sprintrequirements toe te voegen aan de product backlog. Op die manier werden toch enkele belangrijke principes van SCRUM of agile werken aangehouden.
4 Case 2: Infrahernieuwing voor kernapplicaties
4.1 Projectvraag
Een grote onderneming in de publieke sector wordt geconfronteerd met hardware die ‘end of life’ is. Op die infrastructuur draaien het merendeel van de kritieke businessapplicaties (ERP, CRM, …). Die applicaties zijn sterk geïntegreerd met andere applicaties die veelal sturend zijn voor de productie (bv. productieplanning medewerkers) of de klantencontacten (bv. onlineverkoop). Ruw geschat maken ongeveer 8.000 tot 10.000 gebruikers dagelijks gebruik van die applicaties. Het bedrijf is 7 dagen per week actief gedurende 24 uur.
Het project wordt 18 maanden voor de einddatum geïnitieerd.
4.2 Oplossing
Het bedrijf ziet die hernieuwing als een opportuniteit om de technologische onderbouw van haar kritieke applicaties te evalueren en waar mogelijk te moderniseren. Dergelijke hardware gaat doorgaans vijf jaar mee en een bedrijf van die omvang kan niet regelmatig zware interventies organiseren op zijn kernapplicaties.
Er worden twee sporen gevolgd:
1. Spoor 1: technologie en infrastructuur a. bepalen van de juiste (toekomstgerichte) infrastructuur, waarbij eveneens de architectuur van de infrastructuur en de betrokken applicaties wordt herbekeken; b. selecteren van de juiste hardwareleverancier; c. installeren en activeren van de geleverde hardware volgens de vastgelegde principes (architectuur, performantie, continuïteit, backup, …).
2. Spoor 2: applicatie a. actualiseren van het applicatielandschap, inclusief interfaces met de randapplicaties; b. selecteren van een partner die de technische migratie (‘lift & shift’) kan uitvoeren; c. gefaseerd uitvoeren van de migratie van de applicaties naar de nieuwe infrastructuur, inclusief testen. Daarbij dient bijzondere aandacht te worden besteed aan de continuïteit van de operaties.
4.3 Plan van aanpak
Uit de beperkte context hierboven kunnen we afleiden dat er enerzijds veel afhankelijkheden zitten tussen spoor 1 en 2. Anderzijds hebben we te maken met een erg groot project met een lange doorlooptijd waarbij grote blokken werk samen dienen te worden uitgevoerd. Dan is het op projectniveau quasi onmogelijk om alle stukjes werk als product backlog of vervolgens als sprint backlog te gaan organiseren zonder de onderlinge afhankelijkheden in gevaar te brengen.
We opteren hier voor een gefaseerde aanpak, waarbij alle fases worden doorlopen per spoor. Beide sporen starten wel niet gelijktijdig. Spoor 2 (applicaties) heeft inhoudelijk bepaalde linken met spoor 1 waardoor we moeten wachten op duidelijkheid op die punten. Binnen bepaalde fases wordt er dan weer wel gekozen om enkele SCRUM-principes aan te houden. Dat was typisch het geval binnen de testfase. De scope van de testen werd per periode (‘sprint’) bepaalt en volledig doorlopen (testen, bug fixing, retest, validatie). De workload – bepaald door het aantal uit te voeren testscripts – werd zo bepaald dat het testvolume binnen de sprintduur van twee weken kon worden afgewerkt.
In de uitvoering of de werkorganisatie werd heel sequentieel gewerkt, wat erg aanleunt bij de -waterfall-principes. Wat waren de beweegredenen om die aanpak te volgen? We doen de evaluatie in volgende tabel.
Tabel 2 Voorbeeld bepaling ontwikkelstrategie Case 2.
Factor
Oplossing
Mensen
Snelheid
Toelichting
We verwezen al naar de integratie tussen applicaties, het groot aantal applicaties en het belang voor het bedrijf van die applicaties. Daarnaast zijn er nog heel wat onzekerheden waardoor een grondige analysefase (‘discovery’) van belang is. Voor het vinden van de gepaste technologie is grondig marktonderzoek nodig.
Het applicatielandschap bestaat typsich uit verschillende omgevingen (sandbox, ontwikkel, test, productie). Alle omgevingen zijn omvangrijk en laten toe om in de diepte te testen en de migratieprocedures te verfijnen. Maar dat vraagt tijd en is niet te vatten binnen de klassieke sprintduur. We verkiezen hier de best practices te volgen en dus met duidelijk gescheiden fases te werken (en dus waterfall).
Ons assessment: complex
We betrekken hier diverse teams bij het project (architecten, infrastructuur experten, system engineers, applicatiebeheerders, sleutelgebruikers, de aankoopdienst enzovoort). Diverse teams, diverse achtergronden, verschillende kennisniveaus, geen zelfde niveau van agile expertise of ervaring.
Voor dat soort technologieprojecten is het cruciaal dat de impact voor de klant (eindgebruiker) zo minimaal mogelijk is. Kwaliteit en een vlotte migratie primeren op snelheid. In dat soort projecten is er voor de klant amper een tussentijds, werkend product dat relevant is. De klant wil tijdens een migratieweekend op het einde geen negatieve impact op zijn werk. Tussentijdse deliverables zijn minder van belang.
Dat is uiteraard anders voor de betrokkenen, de projectmanager, de projectsponsor, maar ze kunnen genoegen nemen met een duidelijke projectplanning met correcte opvolging en transparante statusrapportage tijdens de uitvoering (over de fases heen).
Werd hier de juiste manier van werken gekozen? We worden geconfronteerd met een infrastructuurproject en niet met een softwaredevelopmentproject. Gezien de grote afhankelijkheden tussen de sporen en de noodzaak aan specifieke expertise zijn we overtuigd dat geen enkele andere methode even goed had bijgedragen tot het projectsucces. Het typeproject beperkte de nood aan klanteninteractie, waardoor het aanvaardbaar was om in sporen en fases te werken. Daarnaast was die aanpak ook noodzakelijk om aan goed risicobeheer te kunnen doen. Zelfs in de laatste weken van spoor 1 zijn er elementen duidelijk geworden die invloed hadden op de installatie van de applicaties. De snelheid opvoeren of teveel in parallel werken had mogelijk tot rework kunnen leiden. Dat had niet kunnen worden opgevangen door de incrementele of iteratieve methode.
• Ahlström J. (2015), How to succeed with continuous improvement. New York, NY: McGraw-Hill Companies.
• Baetens, M., PMP (2010), Kwaliteitsbeheersing in project en proces. Brussel: Ehsal Management School.
• Beatty J., & Wiehers K. (2013), Software Requirements. Washington: Microsoft Press.
• Brackx, D., PMP (2010), PMO or not PMO – Is there a standard?. Brussel: X4P.
• Brackx, D., PMP (2010), Schattingstechnieken. Brussel: Ehsal Management School.
• Bradford, N., PMP (2012), The Project Management Office: A Component Approach for Implementing a PMO. Newtown Square, PA: Project Management Institute.
• Buzan, T. (2010), Zakelijk mindmappen – Verbeter je prestaties op het werk. AN Amsterdam: Pearson Education Benelux.
• Covey, S. R. (2004), The 7 Habits of Highly Effective People. New York, NY: Free Press.
• Florentine, S. (2014), How to Use Agile Development to Avoid Project Failures. Geraadpleegd op http:// www.cio.com/article/747787/How_to_Use_Agile_Development_to_Avoid_Project_Failures
• Flyvbjerg, B., & Budzier, A. (2011), Why Your IT Project May Be Riskier Than You Think. Geraadpleegd op http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1
• Galoppin, L., & Caems, S. (2007), Managing Organizational Change During SAP Implementations Boston, MA: SAP PRESS/GALILEO PRESS.
• Haywood, M. (1998), Managing Virtual Teams: Practical Techniques for High-Technology Project Managers Norwood, MA: Artech House.
• Hedeman, B., Vis van Heemst, G. & Frederiksz, H. (2007), Project Management Based on Prince2TM –PRINCE2 Edition 2005 (3rd edition). LJ Zaltbommel: Van Haren.
• International Business Machines Corporation (2011), Keys to Building a Successful Enterprise Project Management Office. Newtown Square, PA: Project Management Institute.
• Jayaswal, B., Patton, P. (2006), Software Development Methodology Today. Geraadpleegd op http://www. informit.com/articles/article.aspx?p=605374&seqNum=2
• Kelly, E., PMP (2009), Crash with Confidence. Orlando, FL: Project Management Institute.
• Kohler, J., PMP (2009), Singing the Configuration Management Blues. Newtown Square, PA: Project Management Institute.
• Kooijman B. (), Wat is Agile? De betekenis van Agile werken. Geraadpleegd op https://agilescrumgroup.nl/ wat-is-agile/
• Larsen, M. (2013), Who Is a Stakeholder? Identifying Key Players in Your Project. Geraadpleegd op http:// www.projectmanagers.net/i/who-is-a-stakeholder-identifying-players-in-your-project/
• Lencioni P. M. (2012), Five Dysfunctions Of A Team. Hoboken, NJ: John Wiley & Sons Inc.
• Leung, P., PMP (2010), Critical Success factors for Global Project Communications. Newtown Square, PA: Project Management Institute.
• Lim, R. (2012), Why You Should Do a SWOT Analysis for Project Management. Geraadpleegd op http:// project-management.com/why-you-should-do-a-swot-analysis-for-project-management/
• Mulcahy, R., PMP (1999), Top Reasons Projects Fail. Newtown Square, PA: Project Management Institute.
• Nessl, D., PMP (2009), Configuration Management Primer for Project Managers. Newtown Square, PA: Project Management Institute.
• Ohlendorf, A., Conflict Resolution in Project Management. Geraadpleegd op: http://www.umsl.edu/~sauterv/analysis/488_f01_papers/Ohlendorf.htm
• Project Management Institute (2021), A Guide to the Project Management Body of Knowledge – Seventh Edition. Newtown Square, PA: Auteur.
• Project Management Institute (2011), Practice Standard for Scheduling (2nd edition). Newtown Square, PA: Auteur.
• Project Management Institute (2011), Practice Standard for Earned Value Management (2nd edition). Newtown Square, PA: Auteur.
• Project Management Institute (2009), Practice Standard for Project Risk Management. Newtown Square, PA: Auteur.
• Project Management Institute (2006), Practice Standard For Work Breakdown Structures (2nd edition). Newtown Square, PA: Auteur.
• Project Management Institute (1997), Principles of Project Management: collected handbooks from the Project Management Institute. Newtown Square, PA: Auteur.
• Rigby D., Elk S. & Berez S. (2020), Doing Agile Right – Transformation Without Chaos. Boston, MA: Harvard Business Review Press.
• Shipman, M., PMP (2009), Showing PMO Value Through Reporting. Pennsylvania: Project Management Institute.
• Spalek, S., Ph. D. (2005), Critical Success Factors in Project Management. To Fail or not to Fail is the Question! Edinburgh: Project Management Institute.
• Study.com (2021), What is Kanban? - Definition & Types of Systems. Geraadpleegd op https://study.com/ academy/lesson/what-is-kanban-definition-types-of-systems.html.
• Sutherland, J. (2010), Jeff Sutherland’s SCRUM Handbook. Somerville, MA: SCRUM Training Institute.
• Van Riel, J., (2009), De vertaling van BPM? naar BPEL: Een kritische evaluatie (Master’s thesis, Universiteit Antwerpen, België).
• Van Solingen, R., Rustenburg, E., (2010), De kracht van Scrum. Nederland: Pearson Education Benelux.
• Warmer, J., Kleppe, A. (2011), Praktisch UML (5de editie). Nederland: Pearson Informatica NL.
• Young, T. L. (2007), The handbook of Project Management – A practical guide to Effective Policies and Procedures (2nd edition). London: Kogan Page ltd.
177, 204, 218, 223, 225 communicatieproblemen 176 concept 40, 215, 216, 217 configuration management 151, 152, 214 conflictbeheersing 159, 164 contingency 92, 171, 177, 188 crashing 191 cross-platformtest 133 cutover-manager 42 cutover-plan 42, 144, 146
D datamigratie 83, 120, 121 deliverable 27, 29, 30, 40, 41, 67, 181, 202 design 31, 32, 104, 149, 150 developers 117, 219 documentatie 40, 41, 102, 111, 112, 113, 114, 117, 123, 126, 127, 132, 141, 142, 144, 145, 147, 148, 151, 152, 215, 223 doorlooptijd 29, 30, 93, 100, 106, 107, 108, 118, 179, 180, 183, 184, 188, 190, 191, 221
Earned Value Management 242 eindgebruikers 41, 65, 66, 69, 70, 74, 76, 77, 90, 91, 96, 100, 109, 111, 112, 113, 115, 116, 121, 122, 124, 127, 128, 129, 131, 132, 133, 134, 135, 136, 138, 139, 141, 142, 143, 144, 147, 148, 151, 216, 217, 218, 219 eindproduct 128, 216, 218, 219 estimated time to completion (ETC) 197
F fast tracking 191 feedback 40, 102, 109, 114, 127, 128, 129, 132, 214, 215, 216, 217, 218, 220 fixed price 91, 92, 112 flow 55, 71, 115 functional consultant 41 functionaliteiten 131, 132, 133, 134, 135, 136 functionele manager 40, 42
GANTT-chart 106, 107 gebruiksvriendelijkheid 131, 134 gebruiksvriendelijkheidstesten 134 gestructureerd testen 132 go-live 32, 121, 141 handleidingen 66, 132, 145 helpdesk 143, 144, 145, 148, 153, 154 hypercare 104, 142, 144, 147, 226 implementatie 21, 27, 31, 40, 42, 66, 78, 80, 81, 90, 97, 117, 118, 132, 141, 147, 152, 213, 216, 225, 226 incident 149, 153, 154 incident management 153 proceseigenaar 40 process flowchart 67
Process Improvement Team 24 process owner 66 product owner 43, 226 programmaleiding 27 programmamanagement 26, 27, 40 programmamanager 26, 27 projectbaseline 179 projectcharter 22 projecten 21, 23, 24, 25, 26, 27 projectentiteit 40 projectmanagement office (PMO) 40 projectmanagementplan 36, 104, 159, 160, 178, 204 projectmanager 26, 27, 29, 32, 33, 35, 36, 38, 41, 42, 77, 79, 92, 99, 100, 101, 102, 103, 106, 109, 110, 113, 114, 122, 123, 127, 128, 129, 132, 136, 138, 159, 160, 161, 162, 163, 164, 171, 177, 188, 191, 219, 225 projectplan 101, 103, 110, 173 project proposal 90, 92, 93, 99 project risk 242 project scope statement 30 projectsucces 35, 160 projectuitvoering 29, 30, 38 prototype 24, 112, 114, 177, 216
R rapid prototyping 214, 216
Rational Unified Proces 219, 230 regressietesten 135, 145 release 104, 152, 217, 219, 220, 227 requirements 49, 50, 59 requirementsanalyse 26, 47, 49, 50, 51, 52, 56, 57, 58, 60, 63, 65, 66, 75, 78, 88, 111, 112, 116, 216 resource leveling 191 resources 23, 27, 32, 33, 81, 83, 100, 101, 103, 109, 110, 132, 137, 150, 151, 160, 162, 176, 183, 191, 195, 224
RIAD-log 104, 202 risicoanalyse 81, 82 risicobeheer 38, 170, 171, 175 risicomanagementplan 171
RUP 219, 224, 230, 231 S scope 27, 29, 30, 31, 32, 33, 36, 37, 40, 42, 81, 82, 123, 150, 180, 184, 185, 187, 188, 195, 218 scope creep 82 scope statement 81
SCRUM 180, 225, 226, 227, 224, 242 security 119 sequence diagram 118 sequentieel 97, 100, 125, 213, 214, 215, 216 service level agreement (SLA) 141, 142, 143, 150, 154 slack time 106, 108, 109
Trefwoordenregister
113, 115, 116, 125 126, 127, 136, 154, 215, 216, 217, 218, 219, 224, 225, 228 waterfall 214, 215, 216, 226 WBS 103, 106, 181 werkpakket 30, 103, 181 WIP 228, 229 workflow