Scope creep is de vloek van het leven van elke project manager, en tot op zekere hoogte onvermijdelijk zegt Andrew Vermes, technology practice leader bij consulting firma Kepner Tregoe.
Scope creep kan om te beginnen worden vermeden, maar als dat niet lukt, gaan we verder met manieren waarop het kan worden beheerst. Dit is een reeks praktische technieken, geen vervanging voor het grote corpus van theorie en kennis dat u kunt vinden in de Project Management Body of knowledge (PMBoK), Capability Maturity Model for Projects, PRINCE2 of elders.
Er zijn goede redenen voor bedrijven om de vereisten voor een IT-project uit te breiden of te wijzigen: de wereld evolueert, er worden nieuwe bedreigingen voor de gegevensbeveiliging ontdekt, de externe eisen van de klanten veranderen, de technologie gaat zo ver dat het onwaarschijnlijke of hopeloos dure binnen handbereik komt. De slechte redenen om de eisen te wijzigen kunnen worden samengevat als "we hebben er in de eerste plaats niet goed over nagedacht".
U kunt een groot deel van de scope creep vermijden of beheersen door de volgende ideeën op elk project of deelproject toe te passen:
- Beoordeel het proces waar je aan probeert te werken;
- Betrek de belanghebbenden nauw bij de planning;
- 5 waaroms - Ga achter de gestelde eis staan;
- Voortdurend risico- en opportuniteitsbeheer;
- Hou de veronderstellingen zichtbaar.
Beoordeel het proces
Om de uiteindelijke reikwijdte goed in de vingers te krijgen, moet u de belanghebbenden laten deelnemen aan het procesevaluatiewerk. Op die manier zullen zij wijzen op tekortkomingen in het huidige proces, en op punten waar het "echte" proces wezenlijk afwijkt van het afdelingshandboek. Het later ontdekken van verrassingen zal leiden tot onwelkome veranderingen.
Als je een bestaande functie wijzigt, vraag dan enkele gebruikers om door te nemen wat ze doen. Post It notes zijn een uitstekende manier om de stappen vast te leggen. Zorg ervoor dat ze je laten zien, in plaats van te beschrijven wat ze denken dat er gebeurt. Voor een nieuw proces kunnen ze met je meelopen door hun denkbeeldige proces.
Als je het eenmaal hebt vastgelegd, laat ze het dan uitproberen tijdens het werken aan een echte taak. Teken desnoods een paar ruwe schermen op papier en vraag de gebruikersgroep om te zien hoe goed ze werken. Documenteer de hiaten, en blijf ermee spelen tot je een zekere mate van vertrouwen hebt dat het proces doet wat het moet doen.
Witte ruimte is een buzz phrase die de laatste tijd vaak wordt gebruikt. Deze term, die in de jaren negentig voor het eerst onder de aandacht werd gebracht door Alan Brache en Geary Rummler, verwijst naar de constatering dat veel van het belangrijke werk in een organisatie wordt gedaan buiten de "officiële" processtappen om, en zonder rekening te houden met de organisatorische hiërarchie. Als dat niet zo was, zouden veel van onze bedrijven ten onder kunnen gaan.
Eén benadering is om te proberen alles in de procesdozen te forceren. Vanuit het oogpunt van een projectmanager toont dit ook aan dat we moeten zorgen voor de interfaces tussen de processtappen. Wat gebeurt er eigenlijk langs die pijl van de ene stap naar de volgende? Wat doen mensen om waarde toe te voegen die nergens in de processtroom te zien is?
Betrek belanghebbenden nauw bij de projectplanning
Betrek de gemeenschap van gebruikers/belanghebbenden veel meer bij de ontwikkeling van de reikwijdte van het project. De typische aanpak is dat bedrijfs- en systeemanalisten vragen stellen, eisen opstellen en die vervolgens bespreken met de belanghebbenden. De risico's zijn bekend; gebruikers leveren een slecht doordacht wensenlijstje, en blijven dit vervolgens aanvullen en van gedachten veranderen gedurende de ontwikkelingscyclus.
Een typische project scope zal vijf elementen definiëren: wat, waarom, hoe, wanneer, en hoeveel. De definitie van wat het project moet doen - bekend als de projectverklaring is van cruciaal belang, en moet het eindproduct beknopt beschrijven, op een manier die duidelijk maakt aan de gebruikersgemeenschap wat ze krijgen, en de producenten (wij) wat we moeten maken.
Het creëren van de juiste woorden - of beelden in dit stadium is uiterst belangrijk. Het is ook nuttig om de stakeholder groep te laten deelnemen in het produceren van de work breakdown structure. Hoewel het betrekken van hen in de kleinste details contraproductief kan zijn, geeft het hebben van hen daar om te helpen bij het opstellen van de belangrijkste deliverables hen een appreciatie van wat er moet worden gebouwd, en hoe, en dient als een nuttige realiteitscheck.
Projectdoelstellingen (waarom doen we dit?) zijn vaak een bron van scope creep, vooral als we ons vastleggen op een reeks resultaten die het project op zichzelf niet kan leveren.
Een eenvoudige techniek die u kunt gebruiken om de realiteit te toetsen en achter eisen te komen is de vijf waarom's. De vijf waarom's zijn afkomstig van Toyota in Japan, en waren bedoeld om de oorzaak van een probleem te onthullen. Het idee is dat door vijf keer achter elkaar te vragen 'waarom' je het kennisniveau verhoogt dat je nodig hebt om een oplossing te vinden door de wortel van het probleem te begrijpen dat het bedrijf probeert op te lossen.
Wat is er aan de hand?
We kunnen de nieuwe servercapaciteit niet op tijd geïnstalleerd krijgen.
Waarom?
Er zijn beperkingen op het aantal machines per rek
Waarom?
De warmteontwikkeling is hoog
Waarom?
Gebruik van machines van oudere ontwerpen
Waarom?
Omdat de vorige generatie een hoge stabiliteit biedt
Dit korte voorbeeld laat zien dat het onze uitdaging is de historische stabiliteit te handhaven, maar dat we een manier moeten vinden om de capaciteit snel te vergroten. Het helpt ook om de focus te verleggen van het zoeken naar meer ruimte voor server farms naar (misschien) het zoeken naar machines die dezelfde uptime kunnen leveren met minder warmteontwikkeling.
Het is niet altijd zo dat vijf waarom-vragen genoeg zijn. KT is voorstander van wat wordt genoemd vragen stellen aan de leegte - met andere woorden de vraag herhalen tot je zeker weet dat je alle beschikbare informatie of ideeën hebt uitgeput.
Vijf waarom's is ook nuttig om achter de gestelde eis te komen:
We moeten onze CRM database verbinden met het gereguleerde rapportagesysteem
Waarom?
Wij moeten zicht hebben op te melden klachten bij de behandeling van nieuwe verzoeken van klanten
Waarom?
Wij willen ervoor zorgen dat het technisch advies passend is
Natuurlijk varieer je de woorden om niet als een papegaai te klinken: 'Wat bracht je tot die behoefte?' 'Op welke manier helpt dat je?'
Beheer gebeurtenissen
Risicomanagement wordt aanbevolen door elke autoriteit op het gebied van projectmanagement, inclusief de projectmanagement body of knowledge, maar in het echte leven richten risicologs zich maar al te vaak op tastbare, voor de hand liggende risico's zoals 'servers falen' of 'gebouw vliegt in brand' en verzuimen ze om de specifieke projectuitdagingen diep genoeg te onderzoeken. Bij het beheren van de reikwijdte is het belangrijk om zowel te focussen op kansen als op risico's, en alle potentiële afwijkingen van de reikwijdte op dezelfde manier te behandelen.
Wat we zouden moeten nastreven is een voortdurende waardering van de manier waarop veranderingen om ons heen ons project kunnen beïnvloeden of verbeteren. Voor het managen van de reikwijdte is de categorie risico's/kansen die de meeste aandacht zou moeten krijgen de bedrijfsomgeving, en de gebeurtenissen binnen en buiten de organisatie die ons van gedachten zouden kunnen doen veranderen over de eisen
Organiseer wekelijkse issue/risico/opportuniteit sessies met stakeholders. Onpraktisch? Nee - zeker niet als u een eenvoudig kader gebruikt en de vergadering of het gesprek beperkt tot 30 minuten. De belangrijkste vragen zijn altijd:
Welke problemen ziet u die met dit project te maken hebben?
Op welke manier(en)?
Wat is het huidige (feitelijke) effect van deze kwesties, indien dat er is?
Wat is de potentiële (toekomstige) impact?
Lijst van de specifieke risico's, waarschijnlijke oorzaken en mogelijke maatregelen
Lijst van de specifieke kansen, waarschijnlijke oorzaken, potentiële acties
Kies welke risico's en kansen -
- Voorlopig negeren
- Hou goed in de gaten
- Onderneem actie voor
Houd de veronderstellingen zichtbaar
Elk project is gebaseerd op vele veronderstellingen. Deze kunnen betrekking hebben op interne en externe markten, lonen, beschikbare technologie, wettelijke beperkingen, marges voor producten en diensten en zelfs de aard van het bedrijf. De reikwijdte van een project zal waarschijnlijk moeten worden aangepast als er een wezenlijke verschuiving optreedt in de veronderstellingen. Een systeem van vroegtijdige waarschuwing kan ons helpen de verstoring beter te beheersen.
In het uiterste geval zal een belangrijke wijziging van de veronderstellingen betekenen dat het project moet worden stopgezet. Hoe sneller we ons dit realiseren, hoe beter, om verspilling van middelen tegen te gaan. In het eerdere voorbeeld van het technische ondersteuningsteam was een belangrijke veronderstelling - dat gekwalificeerd personeel beschikbaar en goedkoop is - die toen waar was, nu minder waar. En de omstandigheden kunnen schrikbarend snel veranderen.
De lijst van ideeën is niet volledig, maar dit zijn zes dingen die u en uw projectteam snel en met weinig extra inspanning kunnen doen.
Omvang beheren betekent vooral aandacht hebben voor kleine dingen. De aanwijzingen dat dingen aan het veranderen zijn, zijn overal om ons heen, als we er maar voor kiezen ernaar te luisteren en ze te zien.