Wijzigingsprotocol
Waarom?
Wijzigingen zijn inherent verbonden aan bouwprojecten. Je kan ze niet vermijden, maar je moet een manier zoeken om hiermee om te gaan. Een wijziging lost een probleem of een fout op (reactief), of biedt een opportuniteit, maakt het ontwerp beter (proactief).
De overtuiging leeft dat wijzigingen steeds door de klant worden opgelegd, maar wijzigingen ontstaan vaak ook binnen het team. Vaak gaat het ook niet echt over een zuivere wijziging, maar heeft een bepaalde partij verder gebouwd op een fout of een niet bevestigd uitgangspunt.
Wat & hoe?
Randvoorwaarden die nodig zijn om met wijzigingen te kunnen omgaan:
– Het DOEL en de scope van het project moeten duidelijk zijn.
– Het moet duidelijk zijn wat reeds BESLIST is:
Een wijziging kan immers enkel terugslaan op iets wat reeds vastligt. Het team moet dus kunnen verdergaan op een BESLISSINGENLIJST.
In dit kader introduceren we de begrippen ‘Design Freeze’ en ‘Design Freeze Funnel’.
Design Freeze: op een bepaald moment, bij een mijlpaal in het ontwerpproces, wordt het ontwerp “gefreezed”, definitief vastgelegd. Vanaf de Design Freeze ligt het ontwerp vast en kunnen andere partijen, bijvoorbeeld ingenieurs, hun berekeningen en ontwerpen definitief afstemmen op het architectuurontwerp.
De ‘Design Freeze Funnel’ is gebaseerd op de beslissingenlijst. Aan het begin van het ontwerpproces liggen nog alle mogelijkheden open en is nog niets beslist. Gaandeweg worden stap voor stap beslissingen genomen, ligt meer en meer vast, tot we uiteindelijk bij de volledige Design Freeze komen. De Design Freeze is er niet “plots”, maar is dus het resultaat van een evolutie richting een bepaald ontwerp. De “funnel”, de trechter van mogelijkheden, wordt geleidelijk meer beperkt, omdat gaandeweg meer beslissingen worden genomen.
In het geval van een “wijziging” wordt teruggekomen op een bepaalde “beslissing”, en zetten we dus formeel een stap terug in de ‘Funnel’. Vanuit deze definitie kunnen we een wijzigingsprotocol voorstellen:
Stap 1: Vraag de wijziging aan.
Beschrijf de wijziging, en kwantificeer de wijziging.
– Formuleer en motiveer de wijziging.
– Wat betekent de wijziging naar:
Eenvoud in het proces: heel moeilijk (1) tot heel eenvoudig (5)
Impact op het project: heel weinig (1) tot heel groot (5)
Op deze manier kan je de wijziging kwantificeren naar Eenvoud x Impact. Als de score laag is (een heel moeilijke wijziging met slechts beperkte impact op het project) zal de wijziging waarschijnlijk niet doorgevoerd worden. Wijzigingen die eenvoudig door te voeren zijn en een grote impact hebben op het project zijn natuurlijk interessant.
Stap 2: Evalueer de wijziging in groep.
Bespreek de wijziging en beslis in groep.
Is de inschatting Eenvoud x Impact correct?
Wordt de wijziging doorgevoerd of niet?
We houden de voorgestelde wijzigingen bij in een wijzigingen-log.
Stap 3: Verwerk de wijziging.
Welke beslissing wordt herroepen? Dient het doel en/of de scope te worden bijgestuurd? Wat betekent dit voor de planning voor elke partij?
Elke partij neemt de wijziging mee in zijn/haar werkzaamheden.
Stap 4: Evalueer de wijzigingen
Na het afronden van het traject evalueer je samen met het team de wijzigingen-log: welke wijzigingen hebben een positief effect gehad? Hebben we de eenvoud en de impact correct ingeschat? Wat kunnen we hieruit leren voor een volgend project?