Algemeen
Wijzigingsbeheer is het middel waarmee alle verzoeken tot wijziging van een scope baseline worden vastgelegd, geëvalueerd en vervolgens goedgekeurd of afgewezen. De doelen zijn:
- de verzoeken van stakeholders, om wijzigingen in de scope aan te brengen, vast te leggen;
- ervoor te zorgen dat verzoeken alleen worden ingewilligd als zij levensvatbaar en uitvoerbaar zijn;
- de wijzigingen in de bestaande scope te integreren.
Waar de scope aan het begin van de levenscyclus duidelijk is afgebakend, is het voor het succes van essentieel belang dat wijzigingen in goedgekeurde baselines worden beheerst. Voor alle projecten, programma's en portfolio’s moet een strikte wijzigingsbeheerprocedure worden ingevoerd en gehandhaafd. Het moet de stakeholders in staat stellen hun suggesties voor wijzigingen van de scope in te dienen. Hieronder volgt een typische procedure:
De planningsstap zal bepalen hoe het managementteam zal samenwerken met stakeholders om een onderwerp te behandelen dat een belangrijke bron voor een conflict kan zijn. Het kan onder meer gaan om het stellen van limieten aan de toegestane hoeveelheid verandering en moet zeker nauw aansluiten op stakeholdermanagement. Er kan zelfs worden bepaald welke stakeholders een verzoek mogen indienen, wellicht als contactpunt en eerste filter voor hun achterban.
De initiatiestap zal ervoor zorgen dat personen worden gemobiliseerd die over de nodige bevoegdheden beschikken om met de complexiteit van de scope om te gaan. Hiervoor moet soms een orgaan worden aangewezen, de wijzigingsautoriteit, om ervoor te zorgen dat wijzigingsverzoeken niet alleen naar behoren worden beoordeeld, maar dat de procedure ook als open en eerlijk wordt beschouwd.
Planning en initiatie worden vaak uitgevoerd als onderdeel van scopemanagement en worden meestal gecombineerd met de bijbehorende stappen in de configuratiemanagementprocedure.
De eerste specifieke stap in de procedure is wanneer een stakeholder een wijzigingsverzoek indient. De stakeholder moet relevante informatie verstrekken over de aard van de wijziging. Het verzoek wordt ingevoerd in een wijzigingslogboek waarin alle verzoeken en hun status (bijvoorbeeld in behandeling, goedgekeurd, afgewezen of uitgesteld) worden geregistreerd.
Het wijzigingsverzoek wordt beoordeeld om na te gaan welke gevolgen het heeft voor de producten, de resultaten en de baten. Zo nodig kan om nadere opheldering worden gevraagd alvorens te besluiten of een gedetailleerdere beoordeling de moeite waard is. De voorgestelde wijziging kan zonder verdere evaluatie worden afgewezen, waarbij in dat geval de redenen voor de afwijzing zullen worden geregistreerd en de stakeholders feedback zullen krijgen.
Indien een volledige beoordeling gerechtvaardigd is, worden alle opties met betrekking tot de wijziging in aanmerking genomen en geëvalueerd. Om te kunnen worden aanvaard, moet een voorgestelde wijziging gunstig, praktisch en betaalbaar zijn.
Gunstig betekent dat het een positieve impact heeft op de business case, of een andere baten heeft zoals het verminderen van risico. Praktisch betekent dat het zal werken in de context van de specificatie en eventuele andere wijzigingen. Betaalbaar betekent dat er middelen beschikbaar zijn om de verandering te betalen, misschien via een wijzigingsbudget of een reservering.
De gedetailleerde impact op de opleveringsplannen wordt ook beoordeeld en er wordt een aanbeveling gedaan om goed te keuren, af te wijzen, uit te stellen of om meer informatie te vragen. Er worden drempels vastgesteld om te bepalen of de beslissing kan worden genomen door de P3-manager, sponsor of andere leden van het managementteam.
De beslissing wordt vervolgens gecommuniceerd naar het managementteam en de stakeholders, waar nodig met feedback. Door de leerpunten uit de beoordeling vast te leggen, kunnen toekomstige beoordelingen met een soortgelijke technische inhoud worden versneld.
Indien de wijziging is goedgekeurd worden relevante opleveringsplannen geactualiseerd en worden de wijzigingen aangebracht aan bestaande producten, of aan specificaties voor toekomstige producten.
Het is altijd mogelijk dat urgente wijzigingen worden opgelegd of doorgezet zonder het juiste proces. Deze dienen met terugwerkende kracht de wijzigingsbeheerprocedure te doorlopen.
Goedgekeurde wijzigingen moeten worden teruggekoppeld naar het configuratiemanagementsysteem. In sommige gevallen kan een bevriezing van wijzigingen nodig zijn wanneer geen verdere wijzigingen van de scope worden overwogen. Als de opdrachtgever hiermee heeft ingestemd, moet dit als belangrijk besluitvormingspunt worden opgenomen in het scopemanagementplan.
Projecten, programma's en portfolio’s
De meeste wijzigingsverzoeken hebben betrekking op producten die deel uitmaken van een project. Goedgekeurde wijzigingen hebben meestal kostenimplicaties en idealiter worden hiervoor middelen gereserveerd op de projectbegroting. Sommige projecten zullen onderworpen zijn aan contractuele voorwaarden die een belangrijke impact hebben op het wijzigingsbeheer. Bij de in het contract opgenomen betalingsmethoden is het mogelijk dat het bestek niet kan worden gewijzigd, terwijl bij andere betalingsmethoden vooraf een betalingsschema is vastgesteld voor toegestane wijzigingen.
Net als elke ander budget zal een wijzigingsbudget grenzen en toleranties hebben. Als wordt voorspeld dat het werk deze toleranties zal overschrijden, zal de projectmanager dit probleem moeten escaleren naar de sponsor, die mogelijk aanvullende financiering moet zoeken.
Agile projecten gaan heel anders te werk en maakt wijziging een integraal onderdeel van ontwikkeling. Elke iteratie begint met een planningsvergadering die de producten in de iteratie behandelt, verduidelijkt en prioriteert. Soms kunnen kenmerken daarvan wijzigen, maar deze worden gewoon meegenomen in de iteratie.
Wijzigingsbeheer op programmaniveau betreft wijzigingen die betrekking hebben op baten, hetzij omdat een wijzigingsverzoek direct is gericht op een batenprofiel, hetzij vanwege het indirecte effect van projectwijzigingen op baten.
De procedure zal in eerste instantie het effect van een wijzigingsverzoek op de baten beoordelen en vervolgens het effect op de projectonderdelen. Belangrijke wijzigingen in een project kunnen een herverdeling van resources of fondsen vereisen en kunnen een domino-effect hebben op andere projecten.
Sommige wijzigingsverzoeken binnen een project kunnen een domino-effect hebben op andere projecten. Het programmamanagementteam moet zich terdege bewust zijn van de complexiteit van deze onderlinge afhankelijkheden.
Een gestructureerd portfolio is voor haar doelstellingen afhankelijk van de strategie van de onderneming. Dit kan veranderen als gevolg van een veranderende commerciële omgeving en natuurlijk moet het portfolio hierop inspelen. De wijzigingsprocedure is niet echt van toepassing op ‘wijzigingsverzoeken’ die voortkomen uit de bedrijfsstrategie om te beslissen of ze al dan niet worden geaccepteerd. Deze wijzigingen moeten echter nog steeds worden beoordeeld op hun gevolgen voor de doelstellingen van de projecten en programma's die deel uitmaken van het portfolio.
In plaats van een wijzigingsverzoek goed te keuren of af te wijzen, kan de portfolio-versie van de wijzigingsprocedure leiden tot herprioritering of zelfs annulering van sommige projecten of programma's en de identificatie van nieuwe.
Met dank aan het BPUG-team voor de vertaling naar het Nederlands
