Hoeveel verandering kan een organisatie aan

Organisaties kunnen maar in beperkte mate veranderingen aan. Sommige van de organisaties waarmee ik werk zijn zeer flexibel; ze passen zich continu aan aan nieuwe omstandigheden. In andere organisaties gaat verandering moeizaam gaat.

Je gaat je dan afvragen hoe dat komt en hoeveel verandering een organisatie aan kan en wat je kunt doen om maximaal te veranderen en de organisatie niet te overladen.

Waarom veranderen

Je verandert met een reden, om een doel te behalen. Het doel van de meeste verandertrajecten is meestal verbetering. Bijvoorbeeld veranderen van de manier van werken waarmee problemen die er zijn opgelost worden. Of waardoor er sneller of goedkoper gewerkt wordt. De kwaliteit van de producten of diensten beter wordt.

Beter kan ook zijn dat je moet voldoen aan bepaalde eisen, een bepaalde methode of tool moet gebruiken. Als je zo’n verandering n.l. niet doet dat ga je “out of business”, en daar wordt je dan slechter van.

Wanneer start de verandering

Vaak wordt er pas iets veranderd als men het probleem ziet, het probleem herkent en noodzakelijk vindt dat er iets aan gedaan wordt. Er ontstaat commitment,  de veranderingen worden gesteund en er wordt tijd en geld voor vrijgemaakt.

Maar het kan ook eerder. Bijvoorbeeld door te kijken naar de sterktes van een organisatie, of van teams en individuele medewerkers. Die sterktes kun je benutten om continu beter te worden in wat je doet. Vaak zijn dat dan kleinere veranderingen, maar bij elkaar opgeteld hebben die een groot effect.

Als je alleen problemen aanpakt, dan bereik je een gemiddeld niveau. Door je te richten op sterktes kom je boven het gemiddelde uit!

Hoeveel verandering is mogelijk

De mogelijkheden in organisaties om veranderingen op te nemen is beperkt. Mensen overladen met veranderingen werkt averechts, er ontstaat weerstand. Als verandermanager probeer je in te schatten hoeveel verandering een organisatie aan kan. Om daarmee de benodigde veranderingen zo goed mogelijk te begeleiden en te borgen om een blijvend resultaat te hebben.

Met een van mijn klanten heb geëxperimenteerd om te kijken hoeveel veranderingen ze aankunnen. De veranderingen zelf waren klein genoeg en overzichtelijk maar vanwege de complexiteit in de organisatie was de doorlooptijd gemiddeld toch zo’n 6 maanden per verandertraject. Alles achter elkaar zou te lang duren, alles tegelijk was teveel. We hadden iets nodig om de verandertrajecten te managen.

De IT afdeling van een overheidsinstantie waar ik ingehuurd werd had de behoefte om de kwaliteitszorg en procesondersteuning effectiever te maken. Om dat te kunnen doen waren meerdere veranderingen nodig. De organisatie had eerder een CMMI assessment gedaan en vanuit de bevindingen een groot aantal veranderprojecten gestart. Sommige daarvan waren succesvol afgerond, maar er waren ook enkele verbeteringen die lastiger bleken te zijn.

Met een bottom-up veranderaanpak ben ik met de kwaliteits- en procesmanagers aan de slag gegaan. Om de hoeveelheid verandering behapbaar te houden zorgde ik ervoor dat er maximaal vier mini-veranderprojecten tegelijkertijd liepen, met daarin veranderingen die enigszins onafhankelijk van elkaar uitgevoerd konden worden. Voordat er met een nieuw veranderproject gestart kon worden moest eerst een lopend verandertraject afgerond worden om te voorkomen dat men met teveel dingen tegelijk bezig was. In een enkel geval werd een verandering tijdelijk geparkeerd om ruimte te maken voor een andere verandering met een hogere prioriteit. Het was ook mogelijk om een verandering te stoppen, bijvoorbeeld als duidelijk wordt dat hij geen toegevoegde waarde meer heeft.

Maandelijks kwam iedereen die betrokken was bij een van de veranderingen bijeen. De status van de veranderingen werd besproken, waarbij gekeken werd hoeveel maanden (iteraties) nog nodig zijn om de verandering af te ronden. Ook presenteerden de medewerkers hun ervaringen, deelden best practices, en evalueerden samen hoe de veranderingen vorderden.

Veranderen met Kanban

Veranderen is niet iets wat je eenmalig doet. Organisaties veranderen continu. Dan is het eigenlijk ook logisch om een aanpak te kiezen die daarbij past, zoals Kanban.

Een Kanban aanpak maakt het mogelijk om:

  • verandering zichtbaar en inzichtelijk te maken
  • het aantal verandertrajecten dat een organisatie tegelijk uitvoert te beheersen
  • met een pull aanpak bottom up veranderingen te doen
  • met veranderingen de gehele keten te optimaliseren

Met een Kanban aanpak kun je aantal veranderingen waar een organisatie mee bezig is (Work in Progress) begrenzen. Als een nieuwe verandering nodig is, moet een andere afgerond of gestopt worden. Je voorkomt dat er teveel tegelijk gebeurd, waardoor de mensen overladen worden en er niets veranderd.

Een ander voordeel van een Kanban aanpak is dat je verandertrajecten start vanuit een behoefte. In plaats van met een “push” aanpak, top down veranderingen doorvoeren, gebruik je een “pull” aanpak om bottom up vanuit de teams en afdelingen veranderingen op te pakken en te steunen.

Kanban kijkt (net zoals Lean) naar de gehele keten en de samenwerking tussen de betrokkenen. Bij software ontwikkeling start de keten met de behoefte van de klanten. Hij eindigt als er producten en diensten geleverd worden. Met een Kanban aanpak optimaliseer je de samenwerking tussen alle deelnemers in de keten.

De veranderingen bij de IT afdeling zijn verbeteringen in hun manier van werken. Gebaseerd op interviews heb ik samen met de stakeholders de behoefte aan verandering in kaart gebracht en de verbeteringen gedefinieerd.

De verandering die gedaan zijn hadden o.a. te maken met betere samenwerking, meer inzicht in de kwaliteit van software producten, effectiever besturing van projecten, behalen van KPIs, beter toepassen van processen, etc. En ook kennisdeling, afstemming van processen, en verlagen van de overhead.

Niet teveel veranderingen tegelijk

Zoals eerder aanggeven heb ik het aantal veranderingen wat tegelijk uitgevoerd werd beperkt to vier mini-projecten. Waarom vier? Enerzijds heb ik mij laten leiden door de projectdriehoek: Kwaliteit, tijd en geld. Voor een project mag je er maximaal twee vast hebben, zodat je de derde kunt beïnvloeden. In een groot veranderproject hebben we bij voorkeur maar één doel: Of sneller, of goedkoper, of beter, niet en en. Dus dan kom je voor het aantal veranderingen wat een organisatie tegelijk aankan uit op één, of misschien twee als het meezit.

Kijk ik naar teams dan is daar zeven (+/- 2) het magische getal wat vaak genoemd wordt voor het aantal mensen in een team. Zeven dingen zijn te overzien, dat is behapbaar. Zeven veranderingen tegelijk leek mij echter veel te veel. Vandaar dat ik met vier heb geëxperimenteerd als Work in Progress (WIP) limiet. En dat beviel goed:

Voor de IT afdeling van een overheidsinstantie werkte de Kanban aanpak goed. Een keer per maand kwamen we bijeen en besprak ik de voortgang met de stakeholders.

Vier veranderingen tegelijk lijkt veel, maar het was wel zo dat de veranderingen niet in hetzelfde stadium zijn. Sommige waren net gestart, andere in volle gang, en weer anderen werden afgerond. Ook waren niet alle stakeholders in alle veranderingen betrokken.  De organisatie kon de vier veranderingen aan. Meer veranderingen tegelijk zou teveel zijn geweest, door er vier te doen bleef de vaart erin.

Bewaken van de samenhang was een belangrijke reden om het overzicht van de veranderingen bij te houden en maandelijks te bespreken. Het stimuleerde ook kruisbestuiving tussen de verbeteringen.

Ik wil hiermee niet suggereren dat het exacte wetenschap is. Belangrijker dan het getal vier is om ervoor te zorgen dat er overzicht is van de lopende en geplande veranderingen. Dat je samen met de stakeholder weet hoe ze bijdragen aan het bedrijfsresultaat. En daarmee prioriteiten aan kunt geven.

Tegelijk heb je met de Kanban aanpak ook een tool om niet te lang door te modderen met een verandering. Als een verandering niet loopt, als het geen voordeel oplevert, de organisatie er niet klaar voor is, stop er dan mee. En pak een andere verandering die wel kan en nuttig is. Daardoor blijf je continu verbeteren!

Hoeveel verandering kan jou bedrijf aan?

Over Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Getagd , , , , , , . Bladwijzer de permalink.

2 Responses to Hoeveel verandering kan een organisatie aan

  1. Johan Roels zeggen:

    Beste Ben,

    Interessante column! Je bespreekt het aantal veranderingen vanuit de gezichtshoek van een organisatie of een team. Interessant is ook het aantal veranderingen te bekijken waarmee elk individu (van het team of organisatie) nu worstelt. Hierbij dien je niet alleen de veranderingen in ogenschouw nemen die het individu ‘doorloopt’ binnen de organisatie, maar ook die veranderingen op macro schaal en micro schaal. Op Macroschaal zijn dat bijvoorbeeld veranderingen waarmee het individu te maken heeft in Nederland (proficiat met de nieuwe regering overigens) of zijn gemeente (om nog maar van veranderingen op wereldniveau te zwijgen, zoals de klimaatverandering). Op Microschaal zijn dat bijvoorbeeld veranderingen waarmee het individu te maken heeft in z’n gezin (nieuw kind op komst, een vechtscheiding, een scheve schaats, …) of z’n vriendenclub, sportvereniging, …

    Dan komt men nogal vlug aan een tiental veranderingen die allen ‘within time and within budget’ moeten afgerond worden. Niet te verwonderen dat er hoe langer hoe meer stress, burnouts en depressies opgetekend worden in onze contreien.

    De oplossing is het synergetisch voordeel in élk van die veranderingen werkelijk realiseren. En hoe doe je dat? Door het Creatief wisselwerkingsproces van binnenuit te beleven (en dan wel met alle partners in elk van jouw veranderingen.

    Zie je nu waarom ik zo vol ben van Creative Interchange ?

    Creatively,
    Johan

    PS ‘Cruciale dialogen’ volgens m’n methodiek is één van de toepassingen van Creative Interchange en leidt tot synergie…

    • Ben Linders zeggen:

      Inderdaad, het aantal veranderingen op individueel niveau loopt vaak flink op. Geen wonder dat mensen er soms genoeg van krijgen (letterlijk).

      Mijn ervaring is ook dat de meeste organisatorische veranderprojecten acteren alsof ze de enige verandering zijn (of de belangrijkste, wat nog erger is).

      Vandaar mijn handreiking met dit mechanisme om de hoeveelheid veranderingen te beperken, niet meer doen dan wat haalbaar is.

      Als de waarde van een verandering niet duidelijk is, dan moet je niet doorgaan. Bij bovenstaande organisatie heb ik een van de veranderingen gestops omdat men er het nut niet van inzag. Grappig genoeg kwam er verzet tegen het stoppen en groeide het inzicht waarom de verandering nodig was. Waardoor we hem opnieuw gestart en afgerond hebben.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

  • Ben Linders – Independent Consultant Agile, Lean, Quality, and Continuous Improvement

    Ben Linders
    Ik help organisaties om effectiever software te ontwikkelen. Neem contact op voor mijn diensten.

    I help organizations to effectively develop software. Contact me to hear about my services.