Waar blijft het applaus?


De analyse is degelijk, de architectuur die je bedacht hebt is beter dan marktconform, helder gedocumenteerd en gepresenteerd. En toch is de ontvangst op zijn best lauw te noemen. Het applaus blijft uit. Wat is hier aan de hand?

In onze blogs hebben we eerder (www.inspearit.nl/7) aandacht gevraagd voor het gedrag van de architect. Aan de hand van 7 handvatten hebben we tips gegeven om effectiever te worden. In deze blog wil ik de aandacht vestigen op De ander, onze stakeholder. Bij voorkeur onze medespeler, maar zo af en toe ook onze tegenspeler. In dat geval moeten we kennelijk meer uit de kast halen dan een goed verhaal om ons doel te bereiken.

Realiseer je dat De ander ook een belang heeft. Niet per sé een afwijkende inhoudelijke opvatting; meestal een van de 3 P's: Poen Power Prestige. Hij of zij is er niet op uit om jou te pesten; je voorstel past gewoon niet in zijn plaatje. En hij is ook maar een mens, dus hij zegt niet wat hij bedoelt, maar hij maakt er een acceptabel verhaal van. Zoiets als: "Goed gedaan, maar voor een besluit van de directie is het wel nodig dat er een business case komt." Je herkent direct dat hier 2 maanden uitstel wordt gekocht. De vraag is dan (dat had je je beter van tevoren af kunnen vragen, maar goed): waar komt die weerstand vandaan? Er kunnen allerlei redenen zijn (zie hiernaast).

De lijst is oneindig lang. De kunst is om te herkennen wat de bron van de weerstand is, en om daar dan slim mee om te gaan. Nu zijn we aangeland in de wereld van Verandermanagement, waar hele bibliotheken over zijn volgeschreven. Dat is echter niet mijn idee. Het punt dat ik wil maken is niet dat architecten specialisten in verandermanagement moeten worden (hoewel dat voor enterprise architecten niet zo'n gekke gedachte is), maar dat we ons voldoende verdiepen in onze tegenspelers. Als iemand het niet wil, kan je blijven uitleggen en business cases schrijven, maar het gaat niet helpen. Interventies die dan meer kans maken zijn bijvoorbeeld het wegnemen van de bedreiging, de persoon isoleren, of je richten op andere stakeholders en zo groepsdwang creëren. De mogelijkheden zijn eindeloos.

Voorbeeld: Een klant vroeg mij om een verbetervoorstel te schrijven voor zijn architectuurafdeling. Toen ik hem duidelijk maakte dat het probleem niet bij zijn architecten lag, maar aan de hele organisatie – of liever het gebrek daar aan – verdween de drive al snel. Mijn interventie was niet om het uit te gaan leggen, maar om het probleem behapbaar te maken: de verwachtingen moest omlaag en het perspectief van een verandertraject met kleine stapjes, maakte het acceptabel. Wat eerst een dood paard leek, werd zo een traject waarbij hij in control was.

Nog een voorbeeld: een klassieker: elk innovatie voorstel strandt op 'geen geld'. Crisis of geen crisis, maar al te vaak is dit een drogreden. In dit geval was de context een slopend conflict over financiering: business units die niet willen betalen voor het algemeen goed, maar tegelijkertijd elke euro bestrijden voor een centraal IT budget. Deze discussie was buiten mijn invloedsfeer, maar door bij herhaling zichtbaar te maken dat de business unit er last van had kon ik wel bijdragen aan de beeldvorming en voorkomen dat er suboptimale oplossingen werden gekozen. Dat is beter dan direct de handdoek in de ring gooien.

Dus als het applaus uitblijft, vraag dan jezelf af wat de ware oorzaak achter weerstand is. Alleen al de vraag stellen, maakt dat je anders in de wedstrijd zit: niet alleen inhoud, maar ook proces. Mijn ervaring is dat het werk dan leuker wordt. Minder frustratie, meer (be)grip, meer samenwerking, meer impact. Dat applaus komt wel.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Good Ideas - Agile en architectuur

    Deze animatie geeft de essentie van agile weer en zet ook de relatie met architectuur op scherp. Maar de kijkers komen niet altijd tot dezelfde conclusies.

    Lees verder
  • ‘Just enough’ architectuur

    In gesprek met collega’s en klanten over hoeveel architectuur een organisatie nodig heeft, lijken we elkaar te kunnen vinden in de formulering ‘Just-enough’. Maar hoeveel is dat dan?

    Lees verder
  • U bevindt zich hier

    Architectuur is bij grotere organisaties een volwassen functie. Enterprise Architectuur wordt ingezet om grip te krijgen op de informatievoorziening. Solution Architecturen worden gemaakt om project specifieke oplossingen in te kaderen.

    Lees verder
  • Niet met 'n Ferrari in de file

    Deze blog gaat over de agile enterprise, en wat er voor nodig is om agile te worden. (Dan komen we vanzelf weer uit bij architectuur, maar net even anders.)

    Lees verder
  • Het stiefkind van de enterprise architectuur

    Ik stel me voor dat u bij het lezen van deze titel onbewust al heeft ingevuld waar ik het over heb. En ik stel me ook voor dat velen van u het goed geraden hebben. De Architectuur van de Technische Infrastructuur, verder afgekort met TIA.

    Lees verder
  • Decision Driven Architecture

    Met een Decision Driven Architectuur ben je in staat optimaal mee te leven met wat de organisatie belangrijk vindt, nu én in de toekomst. Dat lijkt me een vereiste in deze agile tijden blogt Serge Bouwens.

    Lees verder
  • Architectuur veert weer op!

    In november vond het jaarlijkse LAC congres plaats. "Meestal kom ik terug met de conclusie: er waren wel enkele aardige presentaties, vele bekende gezichten, prima verzorgd. Dit jaar was het echter anders", blogt Serge Bouwens. Lees verder.

    Lees verder
  • Zin en onzin van documentatie

    Willen jullie meer of minder documentatie? Minder! Minder! Minder! Lees verder.

    Lees verder