Situationeel veranderen #1 – kijk eerst eens wat er aan de hand is

Als consultant krijg je vaak een heldere opdracht mee, die bijna net zo vaak onjuist is. Recent was ik actief bij een bedrijf dat hardware en software systemen levert binnen de automobiel-industrie. Mijn opdracht: “help ons een standaardproces te ontwikkelen voor al onze projecten”. Achterliggende doelstelling: met een standaardproces is alles overzichtelijker, kunnen projecten gemakkelijker van elkaar leren, zijn best practices beter te delen, enz. Klinkt logisch, dus ik aan de slag.

Ik wilde eerst maar eens goed kijken wat er aan de hand is, dus ik voerde eerst een klein assessment uit. Daarin kreeg ik 3 projecten te zien die, naar hun zeggen, een mooie afspiegeling waren van de organisatie. Helaas was daar weinig standaardisatie in te ontdekken.

Project 1 was min of meer een one-man-show. De projectleider deed zelf ook alle ontwikkeling. Het projectje was klein, hij had zelf alle kennis, en andere mensen kreeg hij niet toegewezen, want die waren nog te druk bezig met andere klussen.

Het tweede project was een standaardproduct dat door deze organisatie in de markt werd gezet. De eerste ontwikkelingen waren meer dan 10 jaar geleden gestart. De originele ontwikkelaars hadden òf het bedrijf verlaten òf waren naar managementfuncties gepromoveerd. Helaas was het product een grote berg spaghetti en het huidige ontwikkelteam zag daar nauwelijks doorheen. Nieuwe functionaliteit kostte daardoor altijd erg veel tijd, alleen al het uitzoeken waar er iets veranderd moest worden was al zeer moeizaam.

Project 3 had, min of meer gedwongen door de situatie, gekozen voor een iteratieve aanpak, terwijl het bedrijf tot nu toe alles als waterval had ontwikkeld.

Eén standaardproces zou deze projecten alleen maar gehinderd hebben. Ik heb er hier dus voor gekozen om op heel globaal niveau enkele standaards te definiëren. Denk hierbij aan enkele vaste management mijlpalen en wat basisregels voor opslag van documentatie.

Daarnaast is nu elk project verplicht zijn eigen proces te beschrijven, binnen de (hele ruime) kaders van het standaard proces.

Positieve resultaten:

  • elk project voelt zich eigenaar van de gevolgde aanpak;
  • deze aanpak is op maat gesneden voor de context van het project;
  • er is geen gezeur met QA controles die compliance aan standaards moeten afdwingen die in de praktijk toch niet te volgen zijn.

De achterliggende doelstellingen zoals ‘leren van elkaar’ en ‘best practices delen’ worden op deze manier natuurlijk niet behaald. Eerlijk gezegd geloof ik ook niet echt (meer) in deze doelstellingen. Deze doelstellingen zijn volgens mij alleen haalbaar in situaties die in het Cynefin framework als Simple en Complicated beschreven worden. Maar omdat vrijwel alle ontwikkelprojecten Complex zijn is dit een doelstelling die in principe niet haalbaar is.
Als we proberen om dit toch te doen krijgen we alleen maar teleurstellende gevolgen. Ten eerste wordt de ‘van elkaar leren’ doelstelling niet behaald. Maar ten tweede wordt ook het gewone werk gehinderd. Standaardprocessen die niet passen vertragen projecten alleen maar, leiden tot lagere kwaliteit en veel frustratie.

Samenvattend: kijk eerst naar de variatie die er is binnen een organisatie, en besluit pas daarna of het zinvol is om standaardprocessen in te voeren.

Dit bericht is geplaatst in Uncategorized. Bookmark de permalink.

Geef een reactie

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