Blog

Tijdens een verandering ontstaat vaak een behoefte om dingen te borgen, dwz vastleggen en inbedden in de organisatie. Met een goede borging veranker je de nieuwe werkwijze, waardoor het resultaat van de verandering blijvend is. Maar hoe beter de borging is, hoe lastiger het losmaken in de toekomst wordt als er veranderd moet worden. Hoe pak je dat dilemma aan?

Een veranderproces bestaat volgens Kurt Lewin uit 3 stappen: Losmaken, veranderen en borgen. Tijdens het losmaken worden bestaande werkwijzen ter discussie gesteld en gekeken of die effectief zijn. Daaruit volgen de veranderingen, zoals aanpassingen in de manier van werken, nieuwe processen of procedures, aangepast organisatiestructuren, en nieuwe hulpmiddelen. Het veranderproces wordt afgesloten met de borging, die ervoor zorgt dat de verandering beklijft en daarmee de nieuwe “standaard” manier van werken wordt. Dat is nodig om te voorkomen dat het nieuwe gedrag wat bij de verandering hoort verwaterd, en daarmee de investering die gedaan is verloren gaat.

Het losmaken, wat vooraf gaat aan de verandering, kost vaak veel tijd en energie. Processen en organisatiestructuren die met een eerdere verandering zijn geborgd gaan  weer op de schop. “Hebben we net alles afgesproken en vastgelegd, en nu moet het weer anders” is een klacht die je dan vaak hoort. Je vraagt je af of dat niet anders kan? Flexibel veranderen, continue in kleine stapjes verbeteren, waarbij je iedere verandering borgt, dat zou wel eens veel effectiever kunnen zijn.

Borgen vanuit het team

Bij borgen denken veel mensen aan top-down verandering, waarbij een manager of opdrachtgever wil dat iets veranderd. Een verandering vanuit de macht in de organisatie. Echter, de de behoefte om te veranderen en te borgen kan ook (en juist!) bottom up zijn. Teams worden steeds meer zelforganiserend, er zijn zelfs al self-organizing organizations. Ik zie steeds vaker de behoefte vanuit teams van medewerkers komen om zaken te borgen, en minder vanuit de top. Na een tijdje samenwerken (bv bij agile na een paar sprints) wil men zaken vastleggen. En tegelijk de flexibiliteit houden om ze weer aan te passen, als blijkt dat het op een andere manier beter kan. Dit is niet top down, maar bottom up verankeren en borgen.

In een agile retrospectives stel ik vaak vragen om uit te vinden wat er goed gegaan is. En of we iets moeten doen om dat vast te houden? Norm Kerth formuleerde deze vraag als een van de “4 key questions”: “What did we do well, that if we don’t discuss we might forget?” (zie Which questions do you ask in Retrospectives?). Er is geen gouden antwoord, ook als de behoefte om te borgen vanuit de mensen zelf komt blijkt het lastig om het te doen. Klassieke valkuilen als “zet maar in onze DoD” (documenteer de beslissing) om daar vervolgens niet meer naar te kijken heb ik zien gebeuren. Maar ik heb ook teams gehad waarmee ik door kon prikken tot de essentie (bv. met Root Cause Analysis), en daardoor het gedrag konden borgen.

Borgen volgens het CMMI

Het CMMI, wat gebruikt worden bij verbetering van software ontwikkeling en management kent maar liefst 10 “generieke praktijken” voor het borgen van veranderingen (op niveau 2).

GG2: Institutionaliseer een beheerst proces (uit CMMI ® voor Ontwikkeling, Versie 1.3):

1. Breng beleid van de organisatie tot stand
2. Plan het proces
3. Stel mensen en middelen beschikbaar
4. Ken verantwoordelijkheden toe
5. Train de mensen
6. Beheer de werkproducten
7. Identificeer en betrek de relevante belanghebbenden
8. Bewaak en stuur het proces
9. Evalueer objectief dat het proces wordt gevolgd
10. Review de status met het hogere management

Mijn mening is dat ze alle 10 een rol kunnen spelen bij het borgen van een verandering, maar afhankelijk van de verandering en de situatie zijn ze niet allemaal even belangrijk. Ik heb veranderingen gezien waarbij het vaststellen van beleid cruciaal was, als er geen een “written policy” was dan gebeurde er niets. Het borgen door het proces te bewaken en te besturen, bv. door kwaliteits- of procesmanagers te laten toezien (de welbekende “politie-agent”) werkt vaak niet. Zeker niet als het als enige wordt gedaan om te borgen, terwijl mensen niet weten wat er anders moet (en waarom), niet de middelen krijgen, en geen training hebben gehad. Niet vreemd dat je dan weerstand krijgt!

Leren in plaats van afdwingen

Terug naar ons dilemma,: Hoe zorg je ervoor dat je veranderingen voldoende borgt, niet te weinig maar ook niet teveel, zodat je bij een volgende verandering eenvoudiger de organisatie kunt losmaken en flexibel, continue veranderd. Een oplossing die ik toepas is om extra aandacht te geven aan de CMMI praktijken 3, 5 en 9. Als je mensen goed traint, coached en begeleid, en ze voldoende middelen geeft om hun werk te doen, dan leren ze een nieuwe vaardigheid door het te doen. Veranderen doe je door te leren! Beschouw je medewerkers als professionals, niet als een resource! Door vervolgens regelmatig te evalueren en waar nodig bij te stellen worden ze er steeds beter in. Uiteraard moet wel gekeken worden waar de procedures en organisatie-structuur belemmerend is voor de verandering, dat moet uiteraard aangepast worden. Maar afdwingen van gedrag is meestal geen effectieve manier van borgen, en werkt toekomstige veranderingen tegen.

Een ontwikkelde vaardigheid is een sterkte, die mensen in de toekomst kunnen gebruiken bij nieuwe veranderingen, ze zijn flexibeler dan regels en structuren. Met een techniek als oplossingsgericht werken kun je sterktes benutten en verder ontwikkelen, met als bijkomend voordeel dat je je medewerkers betrekt bij de veranderingen. Een andere techniek om kennis en ervaringen te delen en te ontwikkelen zijn open spaces, die ook toepasbaar zijn om zelforganisatie te stimuleren, waardoor er minder procedures en structuren nodig zijn om veranderingen te borgen. Ook Lean kan helpen om veranderingen “flexibel” te borgen; lean stelt leren, feedback en betrekken van medewerkers voorop.

Borgen door te leren 

Een tijdje terug was er een interessant discussie in het LinkedIn Lean Quality forum over het nut van PDCA.  De stelling was dat binnen Lean, Toyota KATA steeds meer gebruikt wordt om situaties te oefenen, beter te leren beheersen en te borgen, en daarmee is de wig van PDCA niet meer nodig om veranderingen te borgen. KATA’s en coding dojo’s worden ook gebruik om software ontwikkelvaardigheden (craftmanschip) te verbeteren.

We weten allemaal dat het borgen van veranderingen lastig is. Zowel KATA als PDCA helpen daarbij, de kunst is om in een bepaalde situatie ervan te gebruiken wat het beste werkt. Het is leren door te beleven, door het te doen. Ik denk dat we de wig uit PDCA niet kunnen afschaffen, borgen blijft nodig. Maar het creëren van een Lean cultuur waarin medewerkers, gecoached door hun managers, continue kunnen verbeteren (bv met een Agile aanpak) is een goede ontwikkeling. Vaak hebben de medewerkers dan ook de behoefte om afspraken vast te leggen (standaard!), zoals dat b.v. in Agile/Scrum gedaan wordt met een Definition of Done. Waardoor ze hun eigen wig maken, en PDCA toepassen om teamafspraken te borgen.

Conclusie

De kunst is om veranderingen voldoende te borgen, niet te weinig maar ook niet teveel, zodat je bij een volgende verandering eenvoudiger de organisatie kunt losmaken en flexibel te veranderen. Oefenen en leren van nieuwe vaardigheden en regelmatig evalueren, is in de praktijk vaak effectiever dan afdwingen. Lean en Agile kunnen zeker helpen om continue te verbeteren, bv met KATA, maar borgen mbv PDCA is nog steeds noodzakelijk.

(deze blog is geschreven op 4 mei 2012, en aangepast op 25 maart 2013, aangevuld met de behoefte om te borgen vanuit teams (zelf-organisatie).