6 fouten bij standaardiseren in IT

Er bestaan technische standaarden zoals bvb. het IP internet protocol dat je gebruikt om deze blog te lezen.

We kennen gestandaardiseerde regels van voetbal, golf en schaak.

Bedrijven kunnen een ISO 9000 kwaliteitsstandaard bekomen.

Met Lean Six-Sigma framework verminder je variabiliteit met standaardisatie.

Met het CMMI framework standaardiseer je ontwikkelingsprocessen, met ITIL de Service Processen en met Prince 2 / PMI de Project Management processen.

Ik hoor mensen regelmatig zeggen: “We gaan standaardiseren, en dat is goed, toch?”

Neen, niet altijd.

Waarom standaardiseren?

Standaardisatie betekent dat je een bepaalde manier van werken op grotere schaal gaat toepassen.

Hiermee verminder je variabiliteit en kan je kwaliteits- en veiligheidsnormen garanderen.

Je kan je kosten drukken door schaalvoordeel te halen.

Je kan je proces meten en sturen met Key Performance Indicators (KPI’s).

Wat kan er dan fout gaan met standaardisatie?

Fout #1: een embryo standaardiseren

Een IT departement wou zijn project planning skills verbeteren. Standaard templates werden ter beschikking gesteld en trainingen voorzien.

Toen men de templates wou gebruiken pasten de antwoorden niet in de voorziene velden. Die kinderziekte verraadde dat de template ervoor nooit gebruikt is! Senior project managers verwierpen de templates ook omdat ze de goede praktijken vanuit hun ervaring onvoldoende behandelden, maar daarbuiten onnodige informatie verzamelen. De template heeft zijn nut niet bewezen voor ze op schaal gebruikt werd.

Het povere resultaat?

Projecten die door de templates meer vertraging dan ervoor opliepen, en gefrustreerde project managers.

Waarom zou iemand ongeteste embyonale praktijken willen opschalen en het bedrijf in gevaar brengen?

Een beter manier is nieuwe templates en processen op de kleinst mogelijke schaal testen en valideren. Daarna kan er eventueel opgeschaald worden.

De gestandaardiseerde IT protocollen komen er tenslotte ook enkel na een peer review en gevalideerde resultaten.

Een ongeteste stuk code brengt een gezond bedrijf ook niet naar productie.

Test een concept eerst lokaal. Breng geen embryonaal idee als standaard naar productie.

Fout #2: de duurste oplossing standaardiseren

Volgende keer dat je een koffie bestelt op een terras, een artikel in een winkel aanschaft, of je kleren naar de droogkuis brengt, let er dan eens op of de persoon dit op een voorgedrukt papier of in een formulier invult.

Als dat zo is, kijk naar de velden die beschikbaar zijn, en hoeveel er effectief ingevuld worden? Hoeveel nutteloze informatie wordt verzameld?

Taiichi Ohno heeft het succes van Toyota’s Just-in-time production system beschreven. Het mantra is de productie tijdslijn te versnellen door muda (“無駄”, Japanse term voor werk zonder toegevoegde waarde) actief te verwijderen. Er zijn 8 types van muda. Overprocessing, bvb. nutteloze informatie verwerken, of een architecturale oplossing over-engineeren, is daar één van.

Waar komt die overprocessing vandaan?

De te dure manier van werken komt niet van personen die het slecht menen met het bedrijf. Integendeel.

In mijn ervaring komt ze van gerespecteerde mensen die het goed bedoelen met een bedrijf en willen dat bepaalde probleemsituaties aangepakt worden. “We dienen veld X toe te voegen in de template want situatie Y kan gebeuren en je moet dat toch ook kunnen behandelen?”. Een zin die ondertussen in mijn oren klinkt als een wolf van bureaucratie in een schapenvel van klantvriendelijkheid. Want het is net daardoor dat formulieren buiten hun voegen treden of oplossingen over-engineered zijn.

Wat kan je dan wel doen?

Je kan de voorgestelde template, manier van werken en oplossing kritisch bekijken en verwijderen wat niet strikt nodig is.

Je kan de algemene case (“happy flow“) en uitzonderingen apart behandelen.

Je kan naar een ervaringsdeskundigen luisteren. Wat zit er te veel in volgens hen? Haal dat er zonder schroom uit.

Tip: een “commentaar” veld kan een betere manier zijn om complexe situaties in een formulier op te vangen dan alle mogelijke velden en combinaties te voorzien. In een creatieve omgeving kan dat voldoende zijn.

Fout #3: team dynamiek en motivatie eroderen

McGregor beschreef dat werknemers beter gemotiveerd worden en resultaten boeken door vertrouwen in hun te stellen en hen te ondersteunen (“theory Y”) dan bij een strenge opvolging en controle (“theory X”). In verdere studies is dit principe afgezwakt en afhankelijk gemaakt van context en sector. Het blijft echter sterk overeind voor R&D (cf. literatuuroverzicht in artikel Ecker et al.).

In SAfe Agile is het “maximaliseren van de innerlijke motivatie” een basisprincipe. De leden van het team dienen hun eigen innerlijke motivatie op te bouwen.

Hoe motiveer je een team?

Frederick Herzberg bestudeerde hoe mensen gemotiveerd worden. Omgevingsfactoren dienen in eerste instantie aanwezig te zijn (zoals bvb. een correct salaris, een goede werkrelatie met de collegas ). De omgevingsfactoren spelen een rol als ze zouden ontbreken. Eenmaal ze een goed niveau bereikt hebben verbeteren ze de motivatie niet verder.

Naast de omgevingsfactoren zijn er factoren die de motivatie verder verhogen:

• Mogelijkheid om resultaten te boeken
• Erkenning voor het gedane werk
• Het werk zelf
• Verantwoordelijkheid
• Werkomgeving
• Persoonlijke groei

Door het team en de personen vrijheid te geven in hun interne organisatie verhoogt hun verantwoordelijkheid, de erkenning van het resultaat en hun appreciatie van de werkomgeving. Zelf organiserende teams maximaliseren hun motivatie.

Een standaardisatie geeft limieten op die eigen organisatie van personen en teams en dus rechtstreeks op hun motivatie.

Wat kan je hieraan doen?

• De interne teamwerking niet standaardiseren.
• Via emergent design standaarden laten groeien, of teams intensief betrekken bij pilootprojecten.
• Luisteren naar ervaringsdeskundigen.

Fout #4: creativiteit en snelheid fnuiken

Bij standaardisatie is er één standaard die voor een bepaald deel van het bedrijf opgelegd word. Het opstellen en aanpassen van een standaard vraagt een centrale beslissing.

In het “Modern Management” boek van Samuel Certo en Trevis Certo wordt centralisatie in ondernemingen besproken. Het nodige niveau van centralisatie is voor elk bedrijf anders, en kan als volgt samengevat worden:

• Hoe groter de onderneming, hoe meer nood aan decentralisatie
• Hoe meer de klanten en belangrijke leveranciers fysiek verspreid zijn, hoe meer nood aan decentralisatie
• Hoe diverser de productielijn, hoe meer nood aan decentralisatie
• Zijn snelle beslissingen belangrijk? Meer decentralisatie
• Is creativiteit belangrijk? Meer decentralisatie

Decentralisatie laat teams toe de beste manier van werken te vinden. Het bestaan van die vrijheid op zich alleen al motiveert werknemers om betere en meer creatieve technieken te vinden. (cf. artikel Ecker et al.)

Safe Agile heeft “decentralized decision making” als principe. Enkel beslissingen op lange termijn met sterk schaalvoordeel dienen gecentraliseerd te worden. Alle andere beslissingen (frequente, tijds-kritische en beslissingen die lokale informatie vragen) decentraliseer je.

Standaardisatie past zich beter toe op operationele processen dan op creatieve processen en processen die een snelle beslissing vragen. Voor die twee laatste dient voorzichtigheid geboden, en kan je beter niet standaardiseren.

Fout #5: evolutie stilleggen

De regels van schaak zijn gestandaardiseerd door de officiële schaakfederatie (FIDE). Schaak kent zijn oorsprong uit het 6e-eeuwse Indiaans chaturanga spel. Toen het spel in de middeleeuwen naar Europa kwam is de koningin toegevoegd. De rokade is tussen de 14e en 17e eeuw toegevoegd. De regels zoals we ze nu kennen zijn sinds de 19e eeuw niet meer veranderd, maar er zijn wel nieuwe varianten bijgekomen. In April 2019 is er een nieuw “Chess960” kampioenschap aangekondigd door de FIDE.

De regels van Golf en Voetbal evolueren ook verder. Wie zou er 15 jaar geleden gesproken hebben over de spuitbus om de afstand van de muur bij een vrije trap aan te duiden, en over de VAR (Video Assited Referee)?

Evolutie zit in het hart van management frameworks:

• Deming spreekt over continue verbetering met ‘Plan Do Check Lean/Act’.
• CMMI kent ‘Continous Process Improvement‘.
• ITIL bevat ‘Continual Service Improvement‘.
• Het Agile manifesto omarmt verandering en regelmatige reflecties (retrospectives) ter verbetering.
• Het Safe House of Lean heeft ‘Relentless improvement‘ als pilaar.
• Eric Ries spreekt in zijn best-seller “The Lean Startup” over experimenten en A/B testing die het marktaandeel vergroten.

Teams dienen voldoende ruimte te hebben om te experimenteren, te leren en zo ultiem de performantie continue te verbeteren. Ze mogen hierin niet door standaarden gehinderd worden.

Fout #6: fake news en management groupthink

Met “fake news” worden verzonnen verhalen bedoeld die niet in lijn zijn met de feiten.

Wat in de grootste democratie ter wereld gebeurd, komt ook op de boardroom voor. Beslissingen worden genomen op basis van verbloemde informatie.

Is dat onvermijdelijk?

Niet voor Jack Welch, de CEO van Generic Electric die in 12 jaar tijd zijn bedrijf van 14 miljard dollar naar 490 miljard dollar waarde deed stijgen en volgens Fortune de meest bewonderde, bestudeerde en geïmiteerde CEO van zijn tijdsperk is. Jack Welch deed frequent bezoeken aan zijn vestigingen en sprak regelmatig en uitgebreid met de werknemers op de werkvloer.

Niet voor Taiichi Ohno die met Toyota het concept van “Gemba” – de waarheid op de werkvloer gaan zien – als onderdeel van hun Production System introduceerde. Toyota veroverde de Amerikaanse en wereldmarkt.

Niet voor Irving Janis, Robert Wood en Dr. Carol Dweck die waarschuwen voor het concept van “groupthink“, wanneer een groep zonder kritische toon voorstellen accepteert.

Niet voor de bewuste manager of director die de juiste vragen stelt. Uiteraard dient die een verhaal niet inhoudelijk na te trekken, maar kan wel vragen of een voorstel tot standaardisatie getest is? Door wie gedragen wordt? Wat hebben we er uit geleerd?

Als het niet getest is, kan de manager of board beslissen om het voorstel eerst te testen op het kleinst mogelijke niveau om zo het risico op de werking van het bedrijf te minimaliseren.

Conclusie

Standaardisatie biedt mogelijk schaalvoordelen, maar komt ook met risico’s in IT R&D departmenten.

Je kan volgende elementen aftoetsen voor je een beslissing neemt:

• Is de standaard op kleinst mogelijke schaal getest en gevalideerd? Werkt het echt voor je het wil uitrollen?
• Is het voorstel door een ervaringsdeskundige gechallenged? Bevat ze geen overprocessing of overengineering?
• Doet de standaard geen afbreuk aan de interne organisatie van teams?
• Is het een operationele standaard, en doe ze geen afbreuk aan creatieve processen?
• Is er de mogelijkheid om experimenten te blijven doen buiten de standaard? Kan de standaard evolueren?
• Komt de aan management gepresenteerde informatie overeen met de realiteit?

Als het antwoord neen is op één van bovenstaande vragen, bezint dan eer ge begint.

Literatuur

Byrne, Art. The Lean Turnaround: How Business Leaders Use Lean Principles to Create Value and Transform Their Company. McGraw-Hill Education.

Certo, Samuel C.. Modern Management: Concepts and Skills, Global Edition. Pearson.

Deming, W. Edwards. Out of the Crisis. The MIT Press.

Douglas McGregor, The Human Side of Enterprise (New York: McGraw-Hill, 1960).

Dweck, Carol S.. Mindset. Random House Publishing Group.

Ecker B., van Triest S., en Williams C., “Management Control and the Decentralization of R&D,” Journal of Management 39, no. 4 (2013): 906–927.

Herzberg F., “One More Time: How Do You Motivate Employees?,” Harvard Business Review (January/ February 1968): 53–62.

Leffingwell, Dean. SAFe 4.5 Reference Guide. Pearson Education.

Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. The Crown Publishing Group.

Taiichi Ohno;Norman Bodek;Norman Bodek. Toyota Production System: Beyond Large-Scale Production