Op dit moment vindt er in de pers een discussie plaats over het mislukken van ICT projecten binnen de Nederlandse overheid. Daarbij worden verschillende argumenten als oorzaak en oplossing aangevoerd. Ook de focus vanuit architectuur is hierbij aan de orde gekomen (zie het ingezonden stuk in de Volkskrant van 8 december 2011). Het idee dat architectuur een bijdrage kan leveren bij de het voorkomen van falen onderschrijf ik, maar ook dat architectuur kan bijdragen aan het falen zelf zie ik regelmatig gebeuren.

Basis van het probleem is dat projecten vanuit de basis autistisch zijn. Ik heb de definitie van autisme even opgezocht in wikipedia:

Autisme is een pervasieve ontwikkelingsstoornis die zich kenmerkt door beperkingen in de sociale interactie, de communicatie en zich steeds herhalend gedrag.

Projecten kenmerken zich voornamelijk dat het resultaat, de middelen en de datum van opleveren vooraf zijn beschreven. Met name de combinatie van resultaat en opleverdatum werkt in de hand dat projecten naar binnen gekeerd raken. Als daarnaast het project wordt uitgevoerd door projectleden die alleen binnen het project actief zijn dan heb je al snel de poppen aan het dansen. Waarom zou je immers met je omgeving interacteren als daar vanuit je opdracht helemaal geen reden toe is, jij bent tenslotte aangenomen voor het projectresultaat binnen de gestelde termijnen.

Architectuur kan hierbij een goede bijdrage leveren om de borging met de omgeving en de reeds aanwezige architectuur te bewaken. Bijvoorbeeld door het opstellen van architectuurdocumenten zoals de Project Start Architectuur. In de praktijk zie ik echter twee patronen optreden. Het ene is dat de architect volledig op het project gericht is en zich committeert aan het eindresultaat. Het andere is dat een architect naast dit project nog andere activiteiten heeft en dus de focus moet verdelen. In het eerste geval zal de architect zich moeten gaan committeren aan het resultaat binnen de tijd met als risico dat er geschipperd moet worden met de architectuurkwaliteit. In het anderegeval blijft de architect min of meer een buitenstaander blijft en daardoor nogal eens onvoldoende invloed kan aanwenden in de projectsturing.

Een paar voorbeelden uit mijn dagelijkse praktijk:

• Gezamenlijk traject voor implementatie van een informatiesysteem. Project legt zichzelf een onrealistische deadline op. Deeltijdarchitect poogt om invloed aan te wenden in diverse overleggen maar moet vanwege andere verplichtingen een aantal sessies missen. Gevolg is dat men voor een suboptimale oplossing kiest en dit ook onderkend. Deadline wordt niet gehaald door andere knelpunten, vervolgens wordt er doorgemodderd met de suboptimale oplossing.
• Project voor de implementatie van componenten gebaseerd op open standaarden. Projectarchitect is alleen actief binnen dit project en gaat aan de slag met de uitwerking van de open standaarden. Komt vanuit projectperspectief al snel tot de conclusie dat de standaard voor dit project niet volstaat en past deze dan ook aan. Echter zonder hierover te communiceren met de omgeving (die bestaat niet vanuit de project scope). Bij implementatie een groot probleem omdat de omgeving terecht ageert tegen de oplossing.

Wat zou een oplossing kunnen zijn? De belangrijkste is volgens mij dat architecten in een heel vroeg stadium betrokken zijn bij de project kalender. Zo is er in en vroeg stadium een helder beeld van de aankomende projecten en kunnen architecten hierop anticiperen. Daarnaast moeten we voorkomen dat architecten met hun huidige invulling steeds in een spagaat terecht komen. Architectuur wordt in projecten niet als een middel of resource gezien en dat is een tekortkoming van ons als architect!