Beheer het verschuivende zand van bedrijfsvereisten

Scope creep is de vloek van het leven van elke projectmanager, en tot op zekere hoogte onvermijdelijk, zegt Andrew Vermes, technologieleider bij adviesbureau Kepner Tregoe.

Scope creep kan om te beginnen worden vermeden, maar als dat niet lukt gaan we verder met manieren waarop het kan worden beheerd. Dit is een reeks praktische technieken, geen vervanging voor de grote hoeveelheid theorie en kennis die 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 eisen van een IT-project uit te breiden of te wijzigen: de wereld draait door, er worden nieuwe bedreigingen voor de gegevensbeveiliging ontdekt, de externe eisen van klanten veranderen, de technologie gaat zo ver dat het onwaarschijnlijke of hopeloos dure binnen praktisch bereik komt. De slechte redenen om de eisen te wijzigen kunnen worden samengevat als "we hebben er eerst niet goed over nagedacht".

U kunt een groot deel van scope creep voorkomen of beheersen door op elk project of deelproject de volgende ideeën toe te passen:

  • Beoordeel het proces waaraan je probeert te werken;
  • Betrek de belanghebbenden nauw bij de planning;
  • 5 waaroms - Ga achter de gestelde eis staan;
  • Voortdurend risico's en kansen beheren;
  • Houd de veronderstellingen zichtbaar.

Het proces beoordelen

Om de uiteindelijke reikwijdte goed in beeld te krijgen, moet u de belanghebbenden laten deelnemen aan de procesbeoordeling. Op die manier zullen zij wijzen op gebreken in het huidige proces, en op punten waar het "echte" proces aanzienlijk afwijkt van de afdelingshandleiding. Als u later voor verrassingen komt te staan, zult u ongewenste veranderingen moeten doorvoeren.

Als u een bestaande functie wijzigt, vraag dan enkele gebruikers om te doorlopen wat ze doen. Post It notities zijn een uitstekende manier om de stappen vast te leggen. Zorg ervoor dat ze je laten zien, in plaats van te beschrijven wat zij denken dat er gebeurt. Voor een nieuw proces kunnen ze je door het door hen bedachte proces leiden.

Heb je het eenmaal vastgelegd, laat ze het dan proberen bij een echte taak. Teken desnoods een paar ruwe schermen op papier en vraag de gebruikersgroep om te kijken 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.

White space is een modewoord dat de laatste tijd vaak wordt gebruikt. De term, die in de jaren negentig voor het eerst bekend werd gemaakt door Alan Brache en Geary Rummler, verwijst naar de vaststelling dat veel van het belangrijke werk in een organisatie wordt gedaan buiten de "officiële" processtappen en zonder rekening te houden met de organisatorische hiërarchie. Als dat niet zo was, zouden veel van onze bedrijven kunnen instorten.

Eén benadering is om te proberen alles in de proceskaders te dwingen. Vanuit het oogpunt van een projectmanager toont dit ook aan dat we moeten zorgen voor de interfaces tussen 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 op de processtroom te zien is?

Belanghebbenden nauw betrekken bij de projectplanning

Betrek de gebruikers-/belanghebbendengemeenschap veel meer bij de ontwikkeling van het projectbereik. De typische aanpak is dat bedrijfs- en systeemanalisten vragen stellen, eisen opstellen en dan met de belanghebbenden bespreken. De risico's zijn bekend; gebruikers leveren een slecht doordacht wensenlijstje, en blijven dat aanvullen en veranderen tijdens de ontwikkelingscyclus.

Een typische projectscope definieert vijf elementen: wat, waarom, hoe, wanneer en hoeveel. De definitie van wat het project moet doen - bekend als de projectverklaring - is cruciaal, en moet het eindproduct beknopt beschrijven, op een manier die de gebruikersgemeenschap duidelijk maakt wat zij krijgen, en de producenten (wij) wat wij moeten maken.

Het creëren van de juiste woorden - of beelden in dit stadium is uiterst belangrijk. Het is ook nuttig om de groep belanghebbenden te laten deelnemen aan het opstellen van de work breakdown structure. Hoewel het betrekken van hen bij de details contraproductief kan zijn, geeft het hen een indruk van wat er gebouwd moet worden en hoe, en dient het als een nuttige realiteitscontrole.

Projectdoelstellingen (Waarom doen we dit?) zijn op zichzelf vaak een bron van scope creep, vooral als we een reeks resultaten onderschrijven die het project op zich niet kan waarmaken.

Een eenvoudige techniek die u kunt gebruiken om de werkelijkheid te controleren en achter de eisen te komen is de vijf waarom's. De vijf waarom's vinden hun oorsprong bij Toyota in Japan, en zijn bedoeld om de oorzaak van een probleem bloot te leggen. Het idee is dat je door vijf keer achter elkaar 'waarom' te vragen het kennisniveau verhoogt dat je nodig hebt om een oplossing te vinden door de kern 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 opgewekte warmte is hoog
Waarom?
Gebruik van machine van oudere ontwerpen
Waarom?
Omdat de vorige generatie een hoge stabiliteit biedt

Dit korte voorbeeld laat zien dat het onze uitdaging is om de historische stabiliteit te handhaven, maar dat we een manier moeten vinden om de capaciteit snel te vergroten. Het helpt ook om de aandacht te verleggen van het vinden van 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 waaroms genoeg zijn. KT pleit voor wat zij noemt vragen stellen naar de leegte - met andere woorden de vraag herhalen tot je zeker weet dat je de beschikbare informatie of ideeën hebt uitgeput.

Vijf waaroms is ook nuttig om achter de gestelde eis te komen:

We moeten onze CRM database verbinden met het regulerende 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 varieert u de woorden om niet als een papegaai te klinken: "Hoe kwam u tot die behoefte?" "Op welke manier helpt dat u?

Beheer gebeurtenissen

Risicomanagement wordt bepleit door elke autoriteit op het gebied van projectmanagement, inclusief de projectmanagement body of knowledge, maar in de praktijk richten risicologs zich te vaak op tastbare, voor de hand liggende risico's zoals 'servers falen' of 'gebouw vliegt in brand' en gaan ze niet diep genoeg in op de specifieke projectuitdagingen. Bij het beheer van de reikwijdte is het zaak zich zowel op kansen als op risico's te richten, en alle potentiële afwijkingen van de reikwijdte op dezelfde manier te behandelen.

Wat we moeten nastreven is een voortdurende waardering van de manier waarop veranderingen om ons heen ons project kunnen beïnvloeden of verbeteren. Voor het beheer van de reikwijdte is de categorie risico's/kansen die de meeste aandacht verdient de bedrijfsomgeving en de gebeurtenissen binnen en buiten de organisatie die ons van gedachten kunnen doen veranderen over de eisen.

Wekelijkse issue/risico/kansen sessies met belanghebbenden. Onpraktisch? Nee - zeker niet als u een eenvoudig kader gebruikt en de vergadering of het gesprek beperkt houdt tot 30 minuten. De belangrijkste vragen zijn altijd:

Welke problemen ziet u die verband houden met dit project?
Op welke manier(en)?
Wat is de huidige (feitelijke) impact van deze kwesties, als die er al is?
Wat is het potentiële (toekomstige) effect?
Lijst van specifieke risico's, waarschijnlijke oorzaken en mogelijke acties
Vermeld de specifieke kansen, waarschijnlijke oorzaken, mogelijke acties

Kiezen welke risico's en kansen -
- Voorlopig negeren
- Houd 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, loontarieven, beschikbare technologie, wettelijke beperkingen, marges voor producten en diensten en zelfs de aard van het bedrijf. De projectomvang moet waarschijnlijk worden aangepast als de aannames wezenlijk veranderen. Een vroegtijdig waarschuwingssysteem kan ons helpen de verstoring beter te beheersen.

In het uiterste geval betekent een belangrijke wijziging van de veronderstellingen dat het project moet worden afgesloten. Hoe sneller we dit beseffen, hoe beter, om verspilling van middelen te beperken. In het eerdere voorbeeld van het technische ondersteuningsteam is een belangrijke veronderstelling - dat gekwalificeerd personeel beschikbaar en goedkoop is - die destijds waar was, nu minder waar. En de omstandigheden kunnen beangstigend snel veranderen.

De lijst met 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 is vooral aandacht besteden aan kleine dingen. De aanwijzingen dat dingen veranderen zijn overal om ons heen, als we ervoor kiezen ernaar te luisteren en ze te zien.

Gerelateerd

Projectplanning die tijd bespaart

Verminderen van projectcomplexiteit: Van overbelasting naar productiviteit

Neem contact met ons op

Voor vragen, details, of een voorstel!