Interne en externe belanghebbenden betrekken bij alignment

We kennen in de IT allang het Strategic Alignment Model (SAM) van Henderson en Venkateraman. In dit model worden de ‘strategie’ en ‘operaties’ van de business afgezet tegen die van de IT met als boodschap dat er binnen een organisatie verschillende mogelijkheden zijn waarop beide met elkaar omgaan. De IT kan gewoon doen wat de business vraagt of kan proactiever oplossingen voor bepaalde businessvragen aandragen. Rik Maes breidde dit model uit tot zijn 9-vlaks model om daarmee de verantwoordelijkheden en positionering van de diverse rollen en vooral die van de CIO te illustreren. Maes, Rijsenbrij, Trijens en Goedvolk breidden het 9-vlaks model vervolgens met een derde dimensie uit en wel die van de ontwerpfasen van Capgemini’s IAF: Contextual, Conceptual, Logical, Physical en Transformational.Mijn voorstel is om het 9-vlaks model van Rik Maes op een alternatieve manier uit te breiden en wel met een derde ‘Stakeholder’-dimensie: interne en externe belanghebbenden. Waarom? Omdat IT-processen in toenemende mate trager, duurder en complexer worden, niet alleen vanwege onbegrip tussen business en IT of de gebrekkige aansluiting van de IT-processen of omdat er te weinig modellen voor de vele ontwerpfasen worden gemaakt, maar omdat er steeds meer belanghebbenden bij betrokken zijn. Belanghebbenden die elkaar, vanwege het matige trackrecord van de IT, niet zo erg vertouwen en daarom allemaal geconsulteerd in plaats van geïnformeerd willen worden.In met name grote projecten dreigen de deelprojecten, deelprocessen, de deelproducten en hun belanghebbenden langzaam uit elkaar te drijven. Omdat ze het geheel niet meer overzien en ook niet hun plek daarbinnen, ontstaat de neiging om zich af te schermen van het rumoer en de complexiteit en een eigen waardebeleving te vormen. Een waardebeleving die na verloop van tijd steeds verder afstaat van de oorspronkelijk vraag en doelstelling.Als dit risico dreigt, reageren organisaties vaak door meer management toe te voegen. Dit om aan de exponentieel toenemende behoefte aan coördinatie en overleg te voldoen. Dit heeft twee nadelen. Ten eerste neemt hierdoor de behoefte aan afstemming en overeenstemming alleen maar toe, ook het toegevoegde management moet inwerken en aanhaken. Ten tweede krijgen ontwikkelaars er steeds meer ‘bazen’ bij waardoor ook zij van hun werk worden gehouden met vergaderingen en heidedagen.Anderen zoeken de oplossing in meer architectuur. Er komen vele principes en richtlijnen en/of een overgedetailleerd handboek soldaat en dat wordt met harde hand afgedwongen bij de ontwerpers en ontwikkelaars. Nog los van de hiermee samenhangende risico’s voor het imago van de architectuur en de vraag of iemand zich eraan houdt, zit daar het probleem meestal niet. Het probleem zit veeleer in de vele partijen die een vinger in de requirements- en resources-pap hebben. En dat los je met principes en een handboek soldaat niet op.Sommigen zien heil in een apart regiebureau, dat, als tactisch verlengstuk van de CIO, de projecten en betrokkenen regisseert. Het regiebureau is daarbij met name verantwoordelijk voor de projectportfolio, resourcemanagement, planning en de daarmee samenhangende afstemming met externen. De hierdoor verbeterde werkvoorbereiding is zeer nuttig maar heeft, wanneer dit in de vorm van orkestratie wordt gedaan, het risico dat alle verantwoordelijkheid bij dit regiebureau wordt gelegd en het zichzelf daarmee opblaast. Je kunt niet met één dirigent alle projecten en activiteiten regisseren.Wordt de regievoering echter als een choreografie en dus meer facilitair aangepakt, dan loopt men dit risico veel minder. Op de korte termijn helpt het de eigenaars van de requirements en resources op één lijn te brengen zodat de projectleider en de architect daar niet mee worden opgescheept. Op de langere termijn nemen projectleiders en architecten deze taken, elk voor hun deel, steeds meer over en neemt de verantwoordelijkheid van de regievoerder af. Als we daarbij zoeken naar mechanismen om het afstemmingsprobleem te verkleinen, worden IT-projecten wellicht weer hanteerbaar en minder risicovol. Voor tips aan projectleiders, architecten en regisseurs: zie kader.Drs. ing. Cor Baars is principal consultant bij DNV-CIBIT en onder meer verantwoordelijk voor de Master of Science-opleiding in IT-Architectuur die onder toezicht van Middlese University door DNV-CIBIT wordt verzorgd. Hij doet onderzoek naar toepassingsmogelijkheden van CommonView, het alignmentmodel dat ten grondslag ligt aan dit artikel.