De alignment valkuil

IT-snuggere bedrijven presteren veel beter. Dat blijkt keer op keer uit vergelijkend onderzoek. Tijdens het laatste Landelijk Architectuur Congres presenteerde McKinsey de resultaten van een langlopend onderzoek naar middelgrote Europese banken. Nog recenter verscheen het rapport “Avoiding the Alignment Trap in Information Technology” van MIT Sloan. De bevindingen zijn opmerkelijk gelijksoortig.

Er is maar een kleine groep van bedrijven die echt in staat zijn om IT effectief in te zetten ter ondersteuning van hun bedrijfsstrategie. Een procent of 7 maar. Deze IT-snuggere kampioenen groeien structureel zo'n 35% sneller dan het gemiddelde en besteden toch 6% minder aan hun IT. Ze zijn wel weer in staat om van dat 6% lagere budget maar liefst 45% aan vernieuwingen te besteden; tegenover 29% voor een gemiddeld bedrijf. Dat komt dus neer op een bijna 50% hoger budget voor productontwikkeling. En ze zijn ook nog eens in staat om aanzienlijk sneller dan een gemiddeld bedrijf nieuwe producten op de markt te brengen – een typische cyclus duurt 3-6 in plaats van 6-9 maanden.

Ook andere financiële metrieken, zoals koers-winst verhouding en winst per aandeel, zijn bij deze IT-snuggere business kampioenen significant beter. De klassieke voorbeelden van dit soort bedrijven zijn Wall-Mart, Dell, FedEx, Cisco en EasyJet. Maar het worden er hoe langer hoe meer. Bedrijven als Charles Schwab, Nestlé, De Beers, T-Mobile en National City Corp hebben de weg naar IT-snuggerheid gevonden. En dankzij dit soort onderzoeken begrijpen we steeds beter hoe ze dat voor elkaar hebben gekregen.

De kwestie

De logische vraag is natuurlijk: Hoe wordt u ook een IT-snugger?

De overgrote meerderheid van de bedrijven, zo'n drie kwart, heeft zo'n beetje gemiddelde IT-kosten en groeit net iets minder dan de markt. Hele normale bedrijven. Bedrijven waarvoor de stelling “IT doesn't matter” nog steeds opgeld doet. IT is geen integraal onderdeel van hun bedrijfsvoering, maar een kostenpost. De IT-afdeling wordt een beetje gezien als een lastige supplier. Er werken IT-specialisten die niets van de business snappen en het ook nooit zullen snappen. De IT kost steeds meer, en werkt steeds moeizamer. Outsourcing lijkt de beste uitweg. Er moeten toch zeker betere leveranciers te vinden zijn?

In termen van het MIT Sloan rapport scoren deze bedrijven zowel op het criterium “alignment” en op “effectiviteit” beneden de maat. Als je ze vergelijkt met de IT-snuggere bedrijven, dan zou een simpele conclusie kunnen zijn dat ze vanzelf beter gaan presteren als ze maar minder aan IT gaan uitgeven. Immers, de kampioenen doen het op alle fronten veel beter en geven toch zo'n 6% minder aan IT uit. De onderzoeken tonen echter onomstotelijk aan dat die simpele remedie niet zo maar effectief zal zijn. Je wordt niet gezond door minder geld aan IT uit te geven, je wordt eerder gezond door je geld aan minder IT uit te geven.

Er is een groep bedrijven van een procent of 8, die verreweg het minst aan IT uitgeven Zij groeien niettemin een stuk sneller dan het marktgemiddelde. Deze superieure IT-bedrijven groeien namelijk wel een procent of 10 sneller dan het gemiddelde bedrijf. Hun IT is weliswaar “well-oiled”, maar niet optimaal afgestemd op de groeikansen die business heeft. Het lage kostenniveau hebben ze bereikt door vooral veel te investeren in simpelheid; door vooral veel niet te doen – ook al vraagt de business er nog zo klemmend om. Hun focus ligt op een superieure prijs-kwaliteitsverhouding, en dan is het maximaal terugdringen van heterogeniteit en diversiteit een logische keuze. Zelfs als dat ten koste gaat van groeikansen.

Figuur 1: Een segmentering van bedrijven geïnspireerd op het MIT Sloan onderzoek.

De laatste groep, toch nog zo'n 10%, is helemaal slecht af. Zij betalen een hoge prijs voor een goede alignment. Hun IT kosten liggen 13% boven het gemiddelde, en hun groei ligt 14% onder het gemiddelde. Een sterke alignment in combinatie met een lage effectiviteit van de IT. Deze IT-sukkels bekleden een weinig benijdenswaardige positie, die MIT Sloan treffend de “alignment trap” heeft gedoopt. Alignment als valkuil.

Gevoelsmatig is deze “alignment trap” makkelijk te verklaren. Als het begrip “alignment” wordt uitgelegd als “luisteren naar 'de business' en precies doen wat zij vragen”, dan is het voorspelbare gevolg een complexe lappendeken van verschillende oplossingen voor steeds nieuwe problemen. In de loop van de tijd is 'de business' immers met een veelheid aan problemen geconfronteerd waarbij steeds verschillende mensen met wisselende verantwoordelijkheden steeds andere oplossingen hebben gevraagd. En die zijn steeds braaf naar beste kunnen geleverd. Althans, binnen de gegeven context.

Het nobele streven naar “alignment” is op deze manier vooral een symptoom van een gebrekkige IT-strategie en een onmachtige IT organisatie. Ad-hoc IT is op termijn nou eenmaal kostbaar. Dat weten we al lang. Vooral de kosten voor integratie en onderhoud stijgen dan de pan uit. En dat is uiteindelijk niet in het belang van de business. Een inter-application spaghetti kan zelfs dramatische vormen aannemen. Alleen drastische en pijnlijke maatregelen bieden dan nog een uitweg.

Figuur 2: het strategisch alignment model van Henderson en Venkatraman.

In 1993 hebben Henderson en Venkatraman een nog steeds zeer lezenswaardige analyse gepubliceerd in het IBM systems journal over “Strategic Alignment”. Zij delen de werkelijkheid in twee dimensies in: Strategie versus executie en Business versus IT. Hun betoog is charmant eenvoudig: voor alignment moet je zowel aan de business als aan de IT kant van het spectrum werken aan een “strategische fit” tussen strategie en executie. Tussen business en IT moet je werken aan “strategische en functionele integratie”. Zij spreken dus pas over “strategische alignment” als er een goede afstemming is op de werkvloer, en in de boardroom en tussen boardroom en werkvloer. Met andere woorden: er is pas alignment als de goede dingen gebeuren, en als die dingen ook goed gebeuren. Samenwerking en effectiviteit gaan dan hand in hand. De traditionele “Business en IT” polen versmelten dan in een gemeenschappelijke, integrale enterprise.

Met de kennis die we nu zo'n 15 jaar later hebben, weten we dat er in elk geval voorbeelden zijn van bedrijven die dit stadium daadwerkelijk hebben bereikt. En met enige studie kunnen we de best practices van deze bedrijven leren. Het kan wel degelijk; en het kan ook in uw bedrijf.

De uitweg

De onderzoeken laten een duidelijk en eenduidig beeld zien. Of je nu gevangen zit in de alignment val, of bij de grote massa van IT-suppliers hoort, de weg naar het kampioenschap verloopt via strategische investeringen in enterprise architectuur. In de woorden van het MIT Sloan rapport:

“Contrary to conventional wisdom, the path to IT-powered growth lies first in building high effectiveness and only then ensuring that IT projects are highly aligned to the business.”

Als je gevangen zit in de “Alignment Trap”, laat dan rustig de kloof tussen business en IT een poosje groeien, want dat creëert de nodige rust om de dolgedraaide IT onder controle te kunnen brengen. Dat vereist wel een gezonde dosis lef. Het kost serieus tijd en geld om de IT op orde te brengen, en in die tijd is er geen of weinig ruimte om leuke nieuwe projecten voor de business te doen. Dat is een zure appel. Het vereist leiderschap en uithoudingsvermogen om hier doorheen te bijten. Maar de feiten tonen helder aan dat dit de enige begaanbare weg naar IT-snuggerheid is.

Het laat zich raden dat hoe meer bedrijven de weg naar IT-snuggerheid weten te vinden, hoe meer de achterblijvers in gevaar komen. Zij vallen ten prooi aan de succesvolle bedrijven, of zijn onvoldoende concurrerend om de volgende tegenslag te kunnen doorstaan. Een bedrijf dat in zijn eigen toekomst gelooft, ontkomt er dus niet aan om aan zijn IT-snuggerheid te gaan werken. Hoe sneller de boel op orde is, hoe groter de overlevingskans zal zijn. Dat is iets om even bij stil te staan.

Er is nog een behartenswaardige les uit de onderzoeken getrokken. Als de IT-afdeling tot nu toe niet naar behoren heeft gepresteerd, dan is het in z'n algemeenheid toch beter om met de bestaande mensen serieus te gaan werken aan een vergaande versimpeling van het bestaande landschap, dan om de falende sleutelfiguren in de IT maar te vervangen door nieuwe. De bestaande mensen blijken, met voldoende mandaat en ondersteuning van externe specialisten, namelijk veel sneller in staat om overtuigende resultaten te bereiken, dan nieuwe mensen die de omgeving eerst nog door schade en schande moeten leren kennen.

Zodra de enterprise architectuur op orde is, als je IT superieur is, dan wordt het tijd om de aandacht op IT Governance te richten. Vanuit een solide basis kan er pas een zinvolle dialoog tussen business en IT ontstaan over vernieuwing en groei. Je hoeft toch niet al te snugger te zijn om dat te kunnen begrijpen?

In deze kwestie wordt een actueel architectuurthema op een messcherpe manier uiteengerafeld. Het is de 5^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.

Parodya

De gemeente Dyadam heeft zijn huisvestingsbeleid onder de loep genomen. Het was een beetje een zooitje geworden, met ambtenaren die met de beste intenties volstrekt langs elkaar heen werkten. Er was duidelijk onvoldoende samenhang in de gebouwde omgeving ontstaan. Daarom heeft de gemeente adviesbureau Goiste de opdracht verstrekt om een nieuw, eigentijds procesmodel te ontwikkelen. In het model moet duidelijk gemaakt worden dat Dyadam een moderne gemeente is, die architectuur in al zijn kernprocessen heeft ingebed.

Het verloop

Tijdens de kick-off meeting bleek iedereen reuze enthousiast over dit innovatieve idee. De burgemeester had de meest betrokken ambtenaren persoonlijk opgeroepen om hun agenda vrij te maken voor deze belangrijke meeting. Zelfs de medewerkers die normaal op vrijdag hun deeltijddag hadden, waren er gewoon bij. Het was nauwelijks nog nodig om het belang van het project uit te leggen. Er werd door iedereen actief gebrainstormd, en dat leverde adviesbureau Goiste aan het einde van de bijeenkomst het volgende lijstje met gemeenschappelijke uitgangspunten voor het nieuwe ruimtelijke ordeningsproces op:

• Architectuur is er voor de burgers
• Architectuur mag de snelheid niet in de weg staan
• De communicatie met de burgers staat centraal
• De architectuur ondersteunt het gemeentebeleid
• De gemeente wil maximaal profiteren van de investeringen van de burgers
• De gemeente doet niets te veel en niets te vroeg (daar was nog aardig wat discussie over geweest)
• We spreken een gezamenlijke taal
• Er is een goede aansluiting en ontsluiting
• Er zijn verschillende plangebieden
• We werken optimaal samen

Er was nog wel een behoorlijk verschil van mening omtrent een principe in de sfeer van “De opgestelde regels worden strikt gehandhaafd”. Tegenstanders vonden dat het nieuwe model alle schijn van bureaucratie moest vermijden, terwijl de voorstanders een duidelijk signaal wilden geven dat het afgelopen zou zijn met het gedoogbeleid. Gelukkig wist men elkaar net voor het einde van de sessie te vinden in het compromisvoorstel van de directeur van Goiste, dat inhield dat handhaving in de verdere uitwerking van de opgestelde principes best als een vorm van communicatie met de burger gezien kon worden.

Nu de aftrap voor het project was gegeven, en alle lichten voor het project op groen leken te staan, zou het een koud kunstje worden om de gemeentelijke ruimtelijke ordenings­processen opnieuw vorm te geven. Om aan te geven dat de gemeente de nieuwste ontwikkelingen op het gebied van ruimtelijke ordening en bouwkundige technologie actief volgt, werd besloten dat deze ontwikkelingen de input voor de processen zouden moeten zijn. Gebouwen waren de logische output, maar het kon natuurlijk ook om verbouwingen gaan. Besloten werd om het voorlopig maar op “bouwsels” te houden. Het te ontwerpen proces zou dus verlopen tussen die twee polen.

Alle ambtenaren die in dit proces van nieuwe ontwikkeling tot bouwsel een taak hadden, werden zorgvuldig 1-op-1 geïnterviewd. Het bleken er uiteindelijk niet minder dan 37 te zijn. Het adviesbureau gebruikte een techniek van individuele diepte-interviews om zeker te weten dat er geen zaken over het hoofd gezien zouden worden. De gesprekken duurden gemiddeld twee uur, waarna er een verslag werd opgesteld, dat in een vervolggesprek van een uur werd doorgesproken en waar nodig aangevuld en bijgesteld. Na drie maanden hard werken had men een schat aan informatie verzameld. Men had alleen nog niet met de manager van de vuilophaaldienst kunnen spreken, die was langdurig ziek. Dit werd dan ook noodgedwongen buiten de scope geplaatst.

Na afloop van deze drie maanden moest het eindrapport aan de burgemeester opgesteld worden. Een eerste consolidatie van alle taken bracht aan het licht dat er drie hoofdprocessen waren, die door drie verschillende disciplines ondersteund werden – de gemeenschaps­voorzieningen zoals scholen, buurtcentra, en de bioscoop; het gemeentelijke wegennet en de nutsvoorzieningen zoals water, elektra en riolering. Besloten werd om deze disciplines in verschillende secties in te kaderen, met als indelingscriterium of hun aandachtsgebied zich boven, op of onder de grond bevond. Verder werd er duidelijk onderscheid gemaakt tussen de besluitvormende taak – het beoordelen van de plannen – en de uitvoerende taak – het toezicht houden op de bouw. De taken van het kadaster waren aanvankelijk een probleem, omdat die in beide processen een rol spelen. Besloten werd om deze in een aparte groep van ondersteunende diensten te plaatsen. Wellicht zou de vuilophaal daar in een volgende versie ook nog wel bijgeplaatst kunnen worden.

Figuur 1: Concept model

Uiteraard werd het conceptrapport eerst met de gemeentesecretaris besproken. Die was vol lof over het vele werk dat was verzet, maar hij had ook een flinke dosis opbouwende feed-back. Er moesten nog “een paar puntjes aangepast” worden, om het voor de burgemeester wat “herkenbaarder” te maken. Het moest wat meer aansluiten bij de ambitie van de burgemeester om een “eigentijdse zakelijkheid” uit te stralen. Het mocht nog wel wat “minder ambtelijk”, en wat “hipper”. En een beetje meer “klasse” kon ook geen kwaad, het was tenslotte geen plan voor de gemeente Pauperveen. Een paar fragmenten uit het gesprek:

• 
  
• “De term ‘Bouwsels’, dat kan echt niet. Ik stel voor om daar ‘Bouwkundige oplossingen’ van te maken.”
• “Die drie basisdisciplines, die zijn veel te weinig onderscheidend voor Dyadam en missen een verbindende factor. Kunnen we hier niets met het begrip ‘architectuur’? Dat straalt tenminste kwaliteit en allure uit.”
• “Ik mis de rol het gemeentebestuur in het plaatje. Dat gaat de burgemeester zo nooit goedkeuren. De Raad zou haar vierkant uitlachen.”
• “En nog één ding. Het gebeurt nog wel eens dat we even snel wat moeten neerzetten voor studenten, of asielzoekers, ofzo. Dan bellen we zo’n bedrijf dat binnen een week een stapel containers neerzet. Dat proces staat los van bureaucratisch toezicht, daarom kan het zo snel. Dat moet in het model herkenbaar terugkomen.”

Al met al waren het nog behoorlijk wat verbeterpunten. Zo veel, dat de doorgewinterde mannen van Goiste het even niet meer zagen zitten. Er was tenslotte al zoveel werk gedaan, en dan nog is er zo ongeveer niets goed genoeg. Dat is demotiverend! En over een week moesten ze al met het finale concept bij de burgemeester bespreken. Ten einde raad werd er besloten om diezelfde avond een nog een extra brainstormsessie in te lassen met de voltallige directie van Goiste. De opdracht voor Dyadam mocht immers onder geen beding mislukken!

Die noodgreep bleek geen slechte zet. Nadat men collectief stoom had afgeblazen en elkaar weer wat moed had ingesproken leek de kritiek ineens helemaal niet zo fundamenteel meer te zijn. Al na twee uur was er een enigszins aangepast model, dat ogenschijnlijk aan alle bezwaren tegemoet kwam. Vooral die “Dynamische Architectuur” was een vondst. Grappig toch, hoe één zo’n woord ineens een heel ander beeld schept.

Figuur 2: Finaal concept model

Het moest allemaal natuurlijk nog wel in de beleidsnota verwerkt worden, maar dat zou met wat overwerk nog wel net op tijd gaan lukken. Verder spraken ze af dat de algemeen directeur vast informeel met de burgemeester ging praten om haar een beetje voor te bereiden op de uitkomst en om nogmaals te benadrukken hoeveel belang Goiste hechtte aan de Dyadam account. De burgemeester kon tenslotte ook best een succes gebruiken, dus er was een duidelijk gezamenlijk belang om op te kapitaliseren.

De burgemeester had op het gemeentehuis de reputatie om een enorme bitch te zijn, maar de consultants van Goiste vonden haar in de praktijk eigenlijk best aardig. Ze was erg geïnteresseerd in het verloop van het project, in de medewerking van iedereen en in aanbevelingen die “om tactische redenen” niet op papier waren gekomen. Er was drie kwartier uitgetrokken voor het gesprek, maar het duurde uiteindelijk bijna vijf kwartier – een duidelijk teken van haar commitment aan een positief resultaat. Toen ze na afloop hun aantekeningen naast elkaar legden, bleek dat er eigenlijk nog maar twee cosmetische puntjes in het model aangepast moesten worden. Ze vond de term “Gemeentebestuur” wat te beperkt. Ze refereerde aan allerlei maatschappelijke groeperingen die de besluitvorming mede bepaalden – dat vonden sommige partijen in de Raad namelijk erg belangrijk; aan de rol van andere overheden en aan de nutsvoorzieningen met hun eigen besluitvorming. “Maak daar maar gewoon ‘besturing’ van, dan kan ik er in de Raad wel een mooi verhaal van maken.”

En ze vond die “Bouwkundige oplossingen” van de gemeentesecretaris wel leuk bedacht, maar een beetje “oude politiek”. In de 21^ste eeuw moest het niet gaan om de gebouwen, maar om de beleving van de burgers. “De gemeente Dyadam biedt geen woonruimte, maar woongenot” was haar politieke statement.

Figuur 3: Definitief model

De burgemeester was briljant tijdens de gemeenteraadsvergadering. “Stel”, zo begon ze, “dat er een grote brand is die een aantal families dakloos heeft gemaakt. Tot vandaag zaten we dan vast aan tijdrovende procedures. Vanaf morgen is dat voorbij. Dan kunnen we die families binnen een week aan nieuwe woonruimte helpen. Dat is wat Dyadam wil zijn. Klantgericht, dynamisch en bij de tijd. En dit nieuwe model gaat dat waarmaken.”

De gemeenteraad was unaniem juichend over het “visionaire” model van de burgemeester. De burgers van Dyadam zouden weer “trots” kunnen zijn op hun gemeente. Daar konden alle andere gemeenten “een voorbeeld aan nemen”. Het voorstel werd bij acclamatie aangenomen.

De ambitieuze burgemeester werd na dit eclatante succes al snel benoemd in een grote stad, om ook daar het “Dyadamse model” in te gaan voeren. Goiste mocht zelfs een lezing houden op het Landelijk Ruimtelijke Ordening Congres. Na deze lezing stroomden de opdrachten uit gemeenteland binnen. Men had school gemaakt.

Om over te peinzen

Wat is nu de moraal van dit verhaal?

Een plaatje dat is gemaakt om besluitvorming te ondersteunen is nog niet per definitie geschikt om een organisatie te helpen professionaliseren. Iedere architect weet dat ieder viewpoint zo zijn eigen eisen stelt aan de modellen die worden gebruikt en de wijze waarop ze worden gepresenteerd. Het hoeft niet erg te zijn als er een politiek model wordt gebruikt dat vol slordigheden en inconsistenties zit. Het wordt pas erg als dit politieke model ook zonder een rationalisatieslag bij de implementatie gebruikt wordt. Dat worden alle onvolkomenheden pijnlijk zichtbaar, en in het ergste geval loopt een organisatie ondanks goede intenties en aanzienlijke inspanningen toch volkomen vast door een gebrek aan concrete resultaten.

Het politieke model voor “Werken onder Architectuur” bestaat inmiddels zo’n zeven jaar. De vertaling naar een werkbaar operationeel model is in elk geval nog niet in de openbaarheid gebracht. Dat is een enorm gemis, want het zou het vakgebied een enorme impuls kunnen geven als er een algemeen geaccepteerd en bruikbaar werkmodel voor “Werken onder Architectuur” zou bestaan. Een model dat ook duidelijk afgestemd zou zijn op andere bekende werkmodellen, zoals Prince2, RUP, ITIL en COBIT. Een model dat praktische aanknopingspunten biedt om architectuur in te bedden in de strategische plancyclus. Een model dat de toegevoegde waarde van “Werken onder Architectuur” concreet maakt. Een model dat het mogelijk maakt om best practices uit te gaan wisselen.

Wie doet er mee om zo’n model te ontwikkelen?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 4^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

Gracieus mislukken is oké

Er mislukken veel te weinig IT-projecten. Inderdaad, we zijn in de IT sector – zeker sinds in 1994 het eerste CHAOS rapport van de Standish Group uitkwam – pijnlijk doordrongen geraakt van het besef dat het meerendeel van de projecten mislukt. Sindsdien is het onderzoek regelmatig herhaald, en is het uitkomen van een nieuwe versie van het rapport telkens wel voer voor zure krantenkoppen. “Het gaat beter: nog maar 73% van de IT projecten faalt” - of stellingen van soortgelijke strekking. Vanwaar dan toch de stelling dat er nog te weinig projecten mislukken?

De Kwestie

Eerst maar eens de vraag wie of wat nou eigenlijk bepaalt of een project succesvol is of niet. Een triviale vraag? De Standish Group is er in elk geval heel stellig over. Een project moet binnen de vooraf afgesproken tijdlijnen en binnen het vooraf afgesproken budget de vooraf afgesproken functionaliteit volledig opleveren. Het probleem is dat deze heldere definitie in de praktijk nauwelijks iets te maken heeft met het begrip succes zoals we dat ervaren. Zo zijn er tal van voorbeelden van bedrijven, met Microsoft als lichtend voorbeeld, die in deze termen nog nooit een succesvol project hebben opgeleverd. Hun projecten lopen altijd uit, kosten veel meer dan geraamd, en tot op het allerlaatste moment worden features geschrapt die niet op tijd het gewenste kwaliteitsniveau halen. En dan nog regent het na een marktintroductie van een nieuw product klachten over allerlei gebreken en tekortkomingen. Toch heeft deze praktijk Microsoft bepaald geen windeieren gelegd.

Stel eens dat een project 10% over zijn geplande budget is gegaan, maar ook 30% meer rendement opbrengt, moet je het dan beschouwen als een mislukking? En een project dat veel vroeger dan gepland en tegen veel minder kosten dan geraamd de gevraagde functionaliteit oplevert, dat is toch een daverend succes. Of niet soms?

In het minst ongunstige geval leidt najagen van de vorm van succes die de Standish Group propageert alleen maar tot overdreven defensieve planningen, waarbij alle projecten die ook maar enig risico met zich meebrengen meestal niet eens worden gestart. Een al te defensieve planning is namelijk dermate pessimistisch dat er a priori al een negatieve business case ontstaat. En wordt het project wel gestart, dan is het gevaar levensgroot dat al het toegekende geld ook daadwerkelijk wordt besteed. Het project gaat leven naar zijn rijkdom. Het al te ver doorgevoerde principe van Underpromise en Overdeliver is op die manier een wel erg povere kwaliteitsstrategie.

Een nog minder aantrekkelijk potentieel gevolg is dat projecten van enige omvang worden opgedeeld in een verzameling deelprojecten die elk voor zich zo klein zijn dat ze bijna niet kunnen mislukken. Als iedere simpele activiteit al als een los project wordt georganiseerd, dan is het makkelijk te plannen en de kans op succes wel erg groot. Feitelijk wordt de complexiteit die inherent is aan de gestelde doelen buiten projecten georganiseerd. Er ontstaan vanzelf allerlei formele en informele overlegstructuren en coördinatiemechanismen die formeel niet te boek staan als projectactiviteiten, maar wel degelijk tijd en geld kosten. En de deelprojecten die niet worden gestart omdat de tijd en of het budget voor het product al zijn verbruikt, die tellen in de boekhoudkundige werkelijkheid niet langer als ongerealiseerde functionaliteit. Een dergelijke praktijk doet het waarschijnlijk goed bij de cententellers van de Standish Group, maar zo'n virtuele werkelijkheid zal de reële perceptie van de betrokken stakeholders hoogstwaarschijnlijk op geen enkele manier positief beïnvloeden.

Het komt ook voor dat als gevolg van de drang naar boekhoudkundig succes juist de slimste projectmanagers de meest uitdagende projecten weigeren omdat ze vrezen anders genadeloos afgerekend te worden op het uitblijven van succes. Als het durven te nemen van risico's wordt bestraft in plaats van beloond, dan ligt lafheid op de loer. En het inzetten van minder getalenteerde projectmanagers op de meer uitdagende projecten is zeker geen garantie voor succes.

Waar ging het eigenlijk ook al weer om bij een project als organisatievorm? Zoals zo vaak lopen de definities uiteen. Toch zijn er voldoende overeenkomsten. Een project is tijdelijk, heeft een vooraf gedefinieerd, uniek resultaat als doel en wordt begrensd door afgesproken condities. Een project heeft typisch een multidisciplinaire samenstelling, vaak wordt er over de grenzen van afdelingen samengewerkt, en – heel wezenlijk – een project kent beheersbare risico's. Dit laatste betekent impliciet dat een project geen aangewezen organisatievorm is voor voorspelbare, routinematige, steeds terugkerende activiteiten, ook al gaat het om complexe activiteiten. Het betekent tegelijkertijd ook dat een projectmatige aanpak niet geschikt is voor volstrekt onvoorspelbare, researchmatige of exploratieve activiteiten. Een ontdekkingstocht door ongekarteerd terrein laat zich nou eenmaal lastig plannen. Het vinden van de dader in een moordzaak is ook zoiets. Het maakt niet uit hoe zorgvuldig je het plant, en welke geavanceerde methoden en technieken je hanteert, er is geen enkele garantie te geven dat je binnen tijd en budget met zekerheid de ware dader kunt identificeren.

Projecten hebben dus van nature een gematigd risicoprofiel. Risico's vertalen zich in onzekerheden. Het is dus normaal dat een project niet precies verloopt zoals je van te voren had gepland. Het is ook heel normaal om je dan af te vragen of het wel zinvol is om zo'n project door te zetten. Een organisatie met een laag percentage mislukte projecten moet zich dan ook serieus afvragen of ze wel goed bezig zijn.

Er bestaat ook een heel andere definitie van een succesvol project. Die is misschien wat subjectief, maar sluit wel veel beter aan bij de beleving van de direct betrokkenen. Hij luidt simpelweg dat een project succesvol is als de verwachtingen van de belangrijkste stakeholders nét worden overtroffen. Iedereen voelt wel aan dat verwachtingen lastig te objectiveren zijn. Ze hebben te maken met ervaringen uit het verleden, ze kunnen door allerlei omstandigheden worden beïnvloed, en ze kunnen in de loop van een project bijgesteld worden. Dergelijke argumenten worden door typische pennenlikkers aangevoerd om te onbruikbaarheid van zo'n definitie aan te tonen. In hun simpele, boekhoudkundige werkelijkheid hebben ze ongetwijfeld het gelijk aan hun zijde. Echter, de weerbarstige realiteit van alle behalve de meest simpele projecten toont keer op keer onomstotelijk aan dat indicatoren als “individuele prestaties” en “collectief succes” eenvoudigweg niet in simpele metrieken gevangen kunnen worden. En succesvolle projectmanagers weten dat een actief management van de verwachtingen van stakeholders onmiskenbaar leidt tot een hogere tevredenheid.

Wat te doen?

Er bestaat een krampachtige neiging om eenmaal gestartte projecten koste wat kost tot een goed einde te brengen. Hoe loffelijk doorzettingsvermogen ook is, dit is doorgaans niet in het belang van de organisatie. Alle tijd en resources die in een dergelijk project worden geïnvesteerd blokkeren immers andere, potentieel waardevollere initiatieven.

Gezonde organisaties beschikken over een goed gevulde portefeuille met projectvoorstellen. Het is uitermate wenselijk dat er veel meer goede ideeën zijn, dan er middelen zijn om ze uit te voeren. Dat betekent namelijk dat er scherp gelet moet worden op de kwaliteit van de voorstellen. Een slimme organisatie investeert immers alleen in de allerbeste ideeën.

Dat maakt de vraag opportuun hoe je het best op voorhand kunt vaststellen welk idee het meest kansrijk is. Hoe kun je uit al die voorstellen de projecten selecteren die het hoogste rendement op zullen brengen? Het antwoord op dergelijke vragen is simpel. Dit is voor iedereen die niet paranormaal begaafd is een onmogelijke opgave. Nauwkeuriger geformuleerd: een grondige analyse van de projectvoorstellen zou zodanig veel tijd en geld kosten, en zoveel risico met zich meebrengen, dat die analyse op zichzelf al een projectmatige aanpak zou vereisen. Waarmee de vraag opportuun wordt welke projectanalyse­projecten voorrang zouden moeten krijgen. Want – het laat zich raden – gezien de beperkte hoeveelheid tijd, mensen en middelen kunnen helaas niet alle voorgestelde projectanalyseprojecten uitgevoerd worden. Maar wie bepaalt dan op basis waarvan welke projecten geanalyseerd mogen worden? Er doemt al snel een netelige analysis paralysis op.

Het is een veel betere tactiek om veel meer projecten te starten dan de beschikbare resources toelaten en een evolutionaire aanpak te kiezen waarbij de sterksten automatisch overleven. Huh? Jazeker! Creëer een gezonde competitie tussen een stel opstartende projecten en beslis na verloop van tijd op basis van de feitelijke vorderingen welke projecten ook echt doorgezet worden. Stel dat er een capaciteit is om van 100 ingediende voorstellen er 10 te realiseren. Het zou wel erg toevallig zijn als van al die 100 voorstellen onmiddellijk duidelijk is welke 10 voorstellen het verdienen om gerealiseerd te worden. Maar het is niet zo moeilijk om er 30 aan te wijzen waar de 10 beste voorstellen met aan zekerheid grenzende waarschijnlijkheid tussen zitten. Geeft die 30 de kans om hun plan een slagje dieper uit te werken, en beslis dan welke 15 er nog een iteratie verder mogen. Tegen die tijd is vast wel duidelijk welke 15 in elk geval niet tot de 10 beste voorstellen behoren. Deze projecten mogen gracieus mislukken. Ze hebben een eerlijke kans gehad, de uitgewerkte plannen zijn ten opzichte van de andere plannen (nog) niet goed genoeg. Iedereen kan inzien dat deze projecten onder de gegeven omstandigheden niet rijp genoeg zijn om echt succesvol te worden. Dat is geen schande, dat is 'all in the game'.

Na nog een iteratie wordt het steeds scherper duidelijk welke 10 projecten echt de besten zijn. De business cases zijn uitgehard, alle risico's zijn geïnventariseerd, de belangrijkste risico's zijn al onschadelijk gemaakt en voor de overblijvende risico's zijn de beheersingsmaatregelen benoemd. Het pad voor succes is geëffend.

Is een dergelijke ogenschijnlijk verkwistende procedure zonde van de verspilling? Denk opnieuw! Het creëren van een gezonde competitie is een elementair economisch principe om de gezondste bedrijven uit een groep uit te selecteren. Het blijkt in de praktijk het meest efficiënte mechanisme dat we kennen. Er is, paradoxaal genoeg, geen betere manier bekend om verspilling juist tegen te gaan. Waarom zou ditzelfde principe bij projecten niet net zo goed kunnen werken? Misschien nog wel het mooiste aspect in deze aanpak is dat er een expliciet belang voor de opdrachtgever c.q initiatiefnemer is om tijdens de opstartfase het maximale te doen om de ideale omstandigheden voor een succesvol project te creëren. En dat gebeurt dus ook. En het project dat na zo'n strenge selectie wordt uitverkoren om te worden gerealiseerd, verkeert vanaf het begin in een winning mood. Dat motiveert enorm! Deze combinatie van de beste plannen en de fitste projecten staat garant voor een maximale return on investment. Gegarandeerd.

In deze kwestie wordt een actueel architectuurthema op een messcherpe manier uiteengerafeld. Het is de 4^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.

Wendbaar ondanks Architectuur

Een gewichtige paradox

Voor organisaties die zich serieus bezighouden met moderne, lichtgewicht ontwikkel­processen zoals eXtreme Programming, Scrum of ook wel het meer gangbare DSDM, is het dilemma ongetwijfeld herkenbaar. Deze op zich sympathieke methodieken zijn bij uitstek bruikbaar voor het oplossen van relatief overzichtelijke problemen. Projecten die je met een stuk of 6 medewerkers kunt realiseren zijn ideaal. Echter, zelfs in zulke betrekkelijk overzichtelijke projecten moet je toch wel over de nodige talenten beschikken om goed met de dynamiek in het project om te kunnen gaan. Je hebt heel wat ervaring nodig om op basis van een beknopte user story in korte tijd een voorspelbaar en bruikbaar deelresultaat op te leveren. Een deelresultaat dat bovendien in de toekomst nog moet passen in het grotere systeem, waarvan aanvankelijk alleen nog maar vage contouren bekend zijn. Want dat is immers de crux van Agile Development: alleen het hoogst noodzakelijke wordt gepland, er wordt liefst vanaf dag 1 met bouwen begonnen en er wordt heel snel productie geleverd. Er wordt wel een intensieve betrokkenheid van de klant verwacht om het project in goede banen te leiden. De klant is idealiter dagelijks aanwezig op de werkvloer, hij bepaalt zelf – op basis van de informatie uit het team – waaraan het team moet werken, en vooral ook waaraan niet. Dus als de klant het nut van formele documentatie niet ziet, geen prioriteit geeft aan stresstesten, of niet bereid is om te investeren in uitwijkprocedures, so be it.

Zo’n wendbaar project kan niet alleen op ieder gewenst moment een andere richting ingestuurd worden, maar het kan ook op ieder gewenst moment gestopt worden en desondanks toch een zinvol resultaat opleveren. In de praktijk wordt er natuurlijk pas gestopt als de opdrachtgever tevreden is of als hij om een andere reden stopt met het sponsoren van het project. Er zijn twee duidelijke voordelen: een opdrachtgever kan de ontwikkeling stoppen op het moment dat het systeem precies goed genoeg is; en het wordt makkelijker om de ontwikkeling van een half af systeem om welke reden dan ook een poosje te bevriezen en daarna zonder al te veel problemen weer op te pakken. Dit principe maakt dit type projecten overigens ook wel eXtreem kwetsbaar voor herprioritering, pardon, bezuinigings­operaties, maar dat terzijde.

Als deze manier van werken goed wordt beoefend, dan levert het volgens ingewijden bovengemiddeld elegante oplossingen op en hebben de bouwers bovendien tijdens het project veel fun gehad. Geen wonder dat de populariteit van deze manier van werken vooral onder geeks zo groot is.

Er is ook een downside. Goed beschouwd is complexiteit dodelijk voor lichtgewicht ontwikkelprocessen – die om die reden ook wel magere processen worden genoemd. Dergelijke processen zijn immers vanuit hun aard beperkt schaalbaar. Als je met meer mensen samen moet werken, dan krijg je vanzelf behoefte aan meer ceremonie – de span-of-control van zelf-sturende teams is immers vrij beperkt. En of je nu kiest voor meerdere parallelle teams, of grotere teams, of allebei, er ontstaat onvermijdelijk meer behoefte aan overleg en coördinatie. Trouwens, als de benodigde investeringen groter worden, dan worden de belangen en reputaties die in het geding zijn navenant groter, en zal er ook vanuit die hoek al gauw behoefte zijn aan meer sturing, control of governance.

Nou is er natuurlijk ook in de Agile methodieken wel nagedacht over het omgaan met afstemmingsproblemen bij het ontwikkelen van complexe systemen. Het basisidee is dat je niet alles van te voren probeert op te lossen, en de software die je maakt is dankzij de gekozen aanpak zo goed onderhoudbaar is dat je voortschrijdend inzicht heel makkelijk kunt verwerken. Op die manier kun je door refactoring de veranderingen doorvoeren om allerhande aansluitingsproblemen en voortschrijdend inzicht te verwerken. Dat klinkt heel goed, maar of je nou op die manier een echt ingewikkeld, bedrijfskritisch project tot een goed einde zou kunnen brengen…?

Het minste wat je kunt stellen is dat bovengemiddeld hoog gekwalificeerde, ervaren en gemotiveerde ontwikkelaars vereist zijn om succesvol systemen Agile te ontwikkelen. Ontwikkelaars die al het een en ander hebben meegemaakt, waardoor ze een mate van vakkundigheid hebben ontwikkeld die hen behoedt voor het maken van fundamentele ontwerpfouten. Teamspelers bovendien, die zonder al te veel sturing toch onderling effectief samenwerken - ook met klanten. Eigenlijk meer het type software architecten, die wat ze bedenken zelf bouwen, en wat ze bouwen goed doordenken. Korte lijntjes en zo min mogelijk overdrachtsmomenten, want hoe minder functiescheiding, hoe lichter het gewicht van het proces.

Maar al je daar even over doordenkt, dan betekent dat eigenlijk impliciet dat u uw beste mensen moet inzetten op niet al te complexe projecten! Zwaargewichten inzetten op lichtgewicht uitdagingen. Maar dat ligt niet onmiddellijk voor de hand! Zou u de beste ontwikkelaars die u in huis heeft, echt willen inzetten op eenvoudige klussen, omdat ze daar fun hebben en veel productiever zijn? Maar wie doen dan de complexere, mission critical projecten? Is dat geen schrijnend dilemma?

De uitweg

Gelukkig is er een uitweg uit deze paradox. Agile programmeren kan heel succesvol zijn, mits er een gezonde basis voor is gelegd. Daarmee bedoel ik een rijk platform met generieke enterprise en platform services die het leven van de ontwikkelaars makkelijk maken. En een set van standaarden, richtlijnen en best practices om die servicelaag goed te gebruiken. Minder ervaren ontwikkelaars kunnen zich toeleggen op het realiseren van specifieke functionaliteiten en de enterprise architecten waken over de generieke services. Waar nodig zullen ze deze services pro-actief onderhouden, maar doorgaans begeleiden ze de ontwikkelteams bij het gebruik van deze servicelaag.

De inzet van talent wordt dan overzichtelijk. De zwaargewichten houden zich bezig met de analyse van een complex problemen en de opdeling ervan in een aantal overzichtelijke deelproblemen. Voor de oplossing van deze deelproblemen schetsen ze de contouren en leggen ze principes en regels vast. En binnen zulke duidelijke kaders kunnen minder ervaren of getalenteerde collega’s, uiteraard onder de regie van de enterprise architecten, eXtreem succesvol zijn.

Er is wel een voorwaarde. Het vereist namelijk dat er strategisch geïnvesteerd is in een rijke collectie generieke services. Want alleen dan kan het ontwikkelen van een nieuwe, rijke functionaliteit relatief eenvoudig zijn. Een collectie services die bovendien voortdurend up-to-date gehouden wordt – achterstallig onderhoud in de generieke services zet projecten meteen op achterstand. En dat vereist niet alleen visie, maar ook een masterplan. Een Enterprise Architectuur. Want, om zoveel mogelijk vrijheid te kunnen bieden, moeten nou eenmaal duidelijke lijnen worden gesteld. Enterprise architecten zijn heel goed in staat om het nodige ceremonieel te betrachten in de richting van kritische stakeholders, en tegelijkertijd om op een meer informele manier effectief samen te werken met vakkundige ontwikkelaars en testers. Durf de bouwvergunningen af te schaffen, en schakel in plaats daarvan over op coaching en training-on-the-job.

Kortom: Met de best practices van Agile Development kunt u vooral heel effectief zijn als u ze combineert met de best practices van Werken onder Architectuur. Separation of concerns is het geheim achter de opschaling van lichtgewicht ontwikkelmethoden. En voor ieder viewpoint moet de hoeveelheid ceremonie voortaan afgestemd worden op de daarbij betrokken stakeholders. Logisch toch?

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 2^de in een reeks 'uncommon sense' die op dit weblog gepubliceerd zal worden