18 Okt Zo ingewikkeld is projectmanagement niet – grip op de project scope
Deel 2: Grip op de project scope
Zo ingewikkeld is projectmanagement niet. Althans, op papier. Want verborgen onder een tapijt aan werkafspraken, rapportagestromen, scrum-borden en escalatielijnen, liggen voor jou als project- of programmamanager behoorlijk wat valkuilen op de loer.
In de serie blogs ‘Zo ingewikkeld is projectmanagement niet’, besteden we periodiek aandacht aan één van die valkuilen. In dit tweede deel is dat het verliezen van de grip op de scope van je project.
Wat verstaan we onder de scope van een project?
Een project is volgens PRINCE2 ‘een tijdelijke organisatie die is opgezet met als doel één of meer producten op te leveren volgens een overeengekomen business case.’ Hoe tijdelijk die organisatie is, hangt af van de scope van het project. Deze wordt gevormd door drie elementen: tijd, kwaliteit en de beschikbare hoeveelheid geld.
Iedere projectmanager kent de plaatjes wel, waarin de driehoeksverhouding tussen deze elementen wordt weergegeven: wanneer er onderweg iets binnen een van de elementen verandert, beïnvloedt dat de andere elementen en daarmee de scope van het project.
Wat is het probleem?
Meer dan de helft van de ICT-projecten wordt niet binnen de project scope afgerond. Dat is: als deze al worden afgerond. Er is veelvuldig onderzoek gedaan naar de oorzaken die hieraan ten grondslag liggen. Een aantal veelgenoemde oorzaken worden hieronder nader toegelicht.
De doelstellingen zijn te vaag
Wanneer de precieze probleemdefinitie en het daaruit voortvloeiende doel van het project niet scherp genoeg zijn geformuleerd, leidt dit vroeg of laat tot ruis. Dit vormt vooral een probleem bij grote ICT-projecten. Vage doelstellingen kunnen leiden tot aanpassing of verruiming van eerder geaccordeerde bouwspecificaties en hiermee dus een uitbreiding van de scope van het project. Daarnaast groeit de behoefte aan afstemming onder de stakeholders, omdat zij zich aan het project hebben gecommitteerd met (oorspronkelijk) afwijkende interpretaties van het projectdoel.
De complexiteit is te groot
Een systeemimplementatie staat vaak niet op zichzelf. Ingewikkelde systeemarchitecturen, datamigraties, uitfasering van legacy-systemen en een hoeveelheid aan noodzakelijke interfaces met andere systemen, maken het soms lastig om goed in te kunnen schatten hoe ingewikkeld een project precies is. Een onvoorziene stijging van de complexiteitsfactor in het project, leidt vervolgens tot een exponentiële groei van de behoefte aan resources. Omdat specialistische kennis binnen de organisatie vaak schaars is, leidt dit weer tot een stijging van de kosten, een uitloop op de planning, of concessies ten aanzien van de op te leveren kwaliteit van het eindproduct.
De prioriteit is te laag
Het werd in het vorige punt ook al aangehaald: specialistische kennis is vaak schaars. Hoe groter de projectportfolio van de organisatie, des te meer kans dat de key-resources hun beschikbare tijd moeten verdelen tussen meerdere projecten tegelijk. Zolang de prioriteit van jouw project hoog genoeg is, hoeft dit geen problemen op te leveren. Wanneer er sprake is van een lagere prioriteit, is er een vergroot risico dat er binnen het project gewerkt moet worden met minder ervaren medewerkers, of – nog vervelender – er gewacht moet worden totdat de ervaren medewerker weer beschikbaar komt. Met alle gevolgen voor de planning van dien. Deze consequenties worden zelden in het projectplan opgenomen.
De projectplanning is te opportunistisch
Bij het opstellen van elke projectplanning wordt gewerkt met bepaalde aannames. Achteraf kan blijken dat deze aannames niet op alle fronten even realistisch waren, bijvoorbeeld vanwege de hierboven genoemde punten. Daarnaast speelt politiek in de totstandkoming van de planning geregeld een rol: een initiële door de projectmanager opgestelde planning wordt niet geaccepteerd en een gevraagde versnelling wordt onvoldoende doorvertaald naar de rest van de scope van het project.
Je gaat het pas zien als je het door hebt
Johan Cruijff zei ooit: “Je gaat het pas zien als je het door hebt.” Dit geldt in zekere mate ook voor het behouden van de grip op de scope van je project. Het begint met het tijdig signaleren van onduidelijkheden, wijzigingen in de projectomgeving en politieke beweegredenen. Pas wanneer je deze scherp hebt, ben je in staat ze te vertalen naar de mogelijke consequenties voor je project scope en kun je hierop acteren.
Daarnaast kunnen de volgende tips ten aanzien van effectief ‘project scope management’ je verder helpen
1. Visualiseer de project scope
Weten wat er in de scope van het project valt, betekent nog niet automatisch dat iedereen ook beseft wat er buiten de scope valt. Vaak wordt dit laatste niet expliciet gemaakt, met ruis tot gevolg. Een goede manier om (wijzigingen op) de project scope te communiceren, is door deze te visualiseren in een zogenaamde user story map. Hierin maak je duidelijk welke gebruikersprocessen volledig, gedeeltelijk of niet in scope zijn en wat hier de status van is.
Zie ook http://jpattonassociates.com/user-story-mapping/
2. Betrek de gebruiker vanaf dag één in je projectteam
Veel last-minute toevoegingen aan of wijzigingen in het eindproduct – en daarmee de scope – van je project kunnen worden voorkomen door de gebruiker tijdig en structureel aan te haken in je projectteam. We schreven hier eerder al deze blog over.
Tijdige aanhaking van de gebruiker, zorgt er tevens voor dat eventuele issues of onduidelijkheden eerder worden onderkend, waardoor je sneller in staat bent om de exacte consequenties voor de project scope te bepalen.
3. Hou het simpel
Het is de kunst om als projectmanager de balans te bewaken tussen het opleveren van een werkend product en een complex product waarin alle uitzonderingsgevallen zijn opgenomen. Het is daarbij handig om, ter voorbereiding op eventuele besluitvorming, samen met je projectteam korte kans-impact analyses uit te voeren op verschillende typen functionaliteit. Hiermee zet je de behoefte en noodzakelijkheid af tegen de ICT-kosten voor ontwikkeling en geef je inzicht in de consequenties voor de scope van het project.
Ten slotte is het goed om je te realiseren dat kleinere projecten een vele – volgens sommige onderzoeken wel tot zeven keer – grotere kans van slagen hebben dan grotere projecten. Probeer dus – conform de Agile projectmanagementmethodiek– het (eind-) doel van een project op te knippen in meerdere sub-doelen, welke ook onafhankelijk van elkaar bestaansrecht hebben. Als je hierin slaagt, maakt dat niet alleen het project overzichtelijker, maar tevens de besluitvorming een stuk lichter.
Sorry, het is niet mogelijk om te reageren.