Situatie gewijzigd

Al wie betrokken is bij IT-projecten, is vertrouwd met het optreden van ‘wijzigingen’ en is zich bewust van de noodzaak om die wijzigingen goed te beheren. Dat geldt zowel voor de opdrachtgever en de gebruiker als voor de leverancier en zowel voor interne als voor externe IT-projecten. En toch zien wij bij onze klanten dat het binnen deze projecten vaak ver van duidelijk is wie wijzigingen mag vragen, wie erover beslist, wie ervoor betaalt en wie het effect bewaakt op kwaliteit, tijd en kosten.

Het klinkt vreemd, maar we moeten vaststellen dat bedrijven zich vaak laten verrassen door een gewijzigde situatie: de wijzigingen komen ‘onverwacht’. Dit doet vermoeden dat die bedrijven te weinig inzicht hebben in de herkomst van wijzigingen. Om onze klanten te helpen de situatie beter in te schatten, geven we hen twee mogelijke bronnen van wijzigingen aan.

Enerzijds kunnen wijzigingen optreden omdat de situatie bij het begin van het project niet altijd 100% gekend is. Anderzijds kan de situatie veranderen tijdens de looptijd van het project. Door systematisch te werken met die categorieën, krijgen we een beter zicht op alle onbekenden (en dus mogelijke bronnen van wijzigingen) van het project, op alle mogelijke vlakken:
– de omgeving (bedrijf, markt,enzovoort)
– de productspecificaties
– de noden / vereisten
– de mensen
– de verwachtingen
– de technische mogelijkheden
– de inschatting (tijd en kosten)
– de uitvoering
– de risico’s
– problemen

Wat ook opvalt is hoe vaak een delicaat spel tussen opdrachtgever en leverancier de situatie bepaalt, meer dan een set van regels en afspraken. Op het eerste zicht hebben klant en leverancier immers vaak tegengestelde belangen. Vragen om wijziging (meestal gebruiken we de Engelstalige benaming change requests) worden niet gebruikt voor een optimaal beheer van wijzigingen, met als inzet de best mogelijke oplossing te vinden, maar louter als wapen om de hoogte van de eindfactuur te drukken of op te drijven.

En dat is jammer, want de kost van dat spel kan aardig oplopen: alle partijen zullen zich immers indekken tegen de risico’s. Zo gaan wijzigingen eerder worden vermeden, en discussies kunnen eindeloos aanslepen. In extreme gevallen zal het project zelfs nooit beëindigd worden. Het resultaat is vaak dat alle partijen teleurgesteld zijn in zowel het verloop als het uiteindelijke resultaat van het project. Met andere woorden, het project ontaardt in een spel zonder winnaars.

OPLOSSINGEN VOOR EEN REËEL BEDRIJFSPROBLEEM
Een verhaal over het succesvol beheren van wijzigingen gaat dus veel verder dan het beantwoorden van de vraag: ‘Hoe maak en/of behandel ik een vraag om wijziging?’ Centraal bij het beheren van wijzigingen staat het tot stand brengen en onderhouden van een positief samenwerkingsklimaat waarin klant en leverancier werken aan de beste en meest betaalbare oplossing voor een reëel bedrijfsprobleem.

Over welke middelen beschikt een projectteam om zo’n klimaat tot stand te brengen? In het vorige artikel (in nummer 8 van IT Professional) haalden we al het belang aan van het maken van goede afspraken in het begin van het project: het nauwkeurig bepalen van de scope van het project. In dit nummer zullen we dieper ingaan op het omgaan met wijzigingen ten opzichte van die beginsituatie.

Het uitgangspunt is dat wijzigingen eigen zijn aan projecten, en dat ze niet per definitie ‘problematisch’ zijn. Wel hebben wijzigingen bijna altijd impact op meerdere parameters van het project: einddatum, kost, scope (functionaliteit), kwaliteit, enzoverder. Daarom moeten ze steeds gecontroleerd gebeuren. Enkel wanneer iedereen binnen het team doordrongen is van dat uitgangspunt, is de basis gelegd voor een vlotte samenwerking.

Vervolgens zijn er een aantal eenvoudige principes die een vlotte samenwerking kunnen ondersteunen:

1. Bij het begin van het project bepalen we de scope (zie vorig artikel). Enkel wat in die scope beschreven wordt maakt deel uit van de opdracht van het project. De scope omvat niet enkel de functionaliteit en features van het product, maar ook elementen zoals de training van gebruikers, het overzetten van data, het aansluiten van een oplossing op een bestaande infrastructuur, de aanpassing van de bijhorende processen, ondersteuning en onderhoud, enzovoort. Zo wordt duidelijk wat wel en niet tot het project behoort.

2. Naast het bepalen van de scope maken we ook een duidelijke productbeschrijving: die gaat dieper in op de eigenschappen van het product (bijvoorbeeld functionaliteit, performantie, snelheid, complexiteit en ergonomie). Ze geeft ook aan wat de specifieke acceptatiecriteria zijn van de opdrachtgever, en welke standaarden van toepassing zijn. Op die manier leggen we vast wat we verwachten van het resultaat.

3. Omdat we ons ervan bewust zijn dat er onvolkomenheden zitten in de scope-afbakening en in de productbeschrijving, en dat de situatie in de loop van het project kan veranderen, maken we afspraken over wie beslist over en betaalt voor welke wijzigingen, in welke omstandigheden. Het zogenaamde escalatiepad geeft aan wie beslissingen neemt over wijzigingen en hoe. Zo zorgen we ervoor dat discussies steeds gevoerd worden op het juiste beslissingsniveau.

Op die manier kan een kleine wijziging doorgevoerd worden na een registratie in het issue log en een eventuele bespreking binnen het team, en een grotere wijziging na overleg met de projectmanager, terwijl een ingrijpende wijziging wordt geëscaleerd naar de projectstuurgroep. Door nauwkeurig te definiëren wat een kleine wijziging is en wat een grote, weet elk teamlid perfect wat hij wel en niet zelf mag wijzigen.

4. We voeren spelregels in: als de klant extra’s wil of de vereisten wijzigt, dan betaalt de klant voor de wijzigingen. Heeft de leverancier zich ‘misrekend’ of levert hij iets dat niet voldoet aan de vereisten, dan betaalt de leverancier voor extra werk of herwerk.

5.We documenteren alle wijzigingen en beslissingen rond wijzigingen zorgvuldig, zodat de volledige configuratie van het systeem op elk moment duidelijk blijft, recente wijzigingen snel herzien kunnen worden, en de facturatie van het project vlot kan verlopen.

SCOPE
In sommige gevallen zal die aanpak niet volstaan: wanneer de beginsituatie erg onzeker is en de productvereisten nog onvoldoende gekend, zal het te omslachtig zijn om elke wijziging ten opzichte van deze onzekere situatie te behandelen als een projectwijziging.

In zulke gevallen kunnen methodes zoals DSDM een oplossing bieden. Hierbij werken gebruikers en IT-teams intensief samen om stap voor stap een geschikte oplossing voor het bedrijfsprobleem te vinden.

Ze gaan er daarbij van uit dat het niet waarschijnlijk is dat de ‘ideale’ oplossing voor het bedrijfsprobleem in één beweging voortgebracht kan worden. De scope wordt daarom aanvankelijk enkel in grote lijnen bepaald, en de opdrachtgever spreekt met het uitvoerend team een vast kader af van tijd en kosten. Binnen dat kader krijgt het team de opdracht om een werkzame oplossing voort te brengen. Verbeteringen en verdere ontwikkeling maken eventueel deel uit van een of meerdere vervolgprojecten.

Zulke teams krijgen binnen het kader van hun opdracht een zeer grote autonomie, en kunnen in grote mate zelf beslissingen nemen. Spelregels zijn onder andere dat het team bestaat uit voldoende senior teamleden die bijvoorbeeld representatief zijn voor de uitvoeringsgroep en de gebruikersgroep, zodat beslissingen steek houden. Ook zullen alle wijzigingen en stappen goed gedocumenteerd moeten worden, zodat ze snel omkeerbaar zijn. Verder zal het systeem stapsgewijs getest en geïntroduceerd worden in de bedrijfsomgeving, zodat het effectief gebruikt wordt tegen de tijd van de oplevering. Voor alle projecten waar het wel mogelijk is om vooraf met een redelijke nauwkeurigheid de scope te bepalen, komt het er vervolgens op aan om een heldere procedure voor wijzigingen op te stellen
, zodat elke projectmedewerker op een dagdagelijkse basis weet welke stappen hij moet volgen. In grote lijnen ziet zo’n procedure er als volgt uit.

1. De aanvrager dient een vraag om wijziging in. (Bepaal wie een vraag om wijziging kan indienen en wie niet.)
2.De aanvrager registreert de vraag om wijziging in het issue log. Dit is een lijst met de kerngegevens over elke vraag om wijziging binnen het project.
3. De projectmanager onderzoekt de vraag. Hij analyseert de herkomst en de aard van de vraag (gaat het om een extern event, een vergissing of een vergeten element, een waardevolle toevoeging, een risicovoorval, een gebrek of tekortkoming?). Hij bekijkt of het gaat om een optionele of een noodzakelijke wijziging, of om een wijziging die reeds gebeurd is. Hij evalueert of de wijziging wenselijk of gunstig is voor het project, en wat de impact is op de kwaliteit, en op tijd en kost.
4.De projectmanager neemt een beslissing over de wijziging of escaleert de vraag naar de stuurgroep, die vervolgens een beslissing neemt. Wie beslist, ondertekent de vraag om wijziging.
5. De projectmanager registreert de beslissing in het issue log.
6. De uitvoerders voeren de wijziging uit (of niet).
7. De projectmanager past zonodig het projectplan aan.
8. De projectmanager stuurt de ondertekende vraag om wijziging door naar de administratie voor facturatie.

Ann Van Herreweghe (Ann.vanherreweghe@projectmanagementbelgie.be) is medeoprichter van Project Management Belgium, een onafhankelijk organisatie voor promotie van project management.