Geef de projectarchitect de ruimte

Collega Rob Berentsen en ik leggen in dit artikel uit waarom het vaak wringt tussen architecten en project managers en wat je eraan kunt doen. In maart 2016 verschenen in de Automatiseringgids (PDF.)

Voorkom dat projectmanagers en -architecten vanaf dag één in de clinch liggen

De kans dat een IT-project slaagt is groter als de projectarchitect en de projectmanager goed samenwerken. Een oplossing en de weg ernaartoe hangen immers nauw met elkaar samen. In de praktijk komen we te vaak projectmanagers en projectarchitecten tegen die vanaf dag één met elkaar in de clinch liggen. De projectmanager wordt typisch verweten dat hij zich te veel met de techniek bemoeit, bij elk wissewasje met escalatie dreigt en procedures en afspraken negeert. Op zijn beurt geeft de projectarchitect altijd ‘dat hangt ervan af’ als antwoord, kan hij niets zelf beslissen en ziet hij overal beren op de weg. In het beste geval weet zo’n tweetal nog iets van het project te maken, maar de verstoorde verhouding kan ook bijdragen aan een mislukking. In de ideale wereld trekken de projectmanager en -architect vanaf de eerste dag samen op. Dan schrijft de projectmanager zijn plan van aanpak terwijl de architect direct aan het ontwerp begint. In de praktijk begint de projectarchitect echter vaak op achterstand omdat de architectuurkaders ontbreken. Zoals de projectmanager met zijn opdrachtgever afspraken maakt over tijd, scope en middelen, zo heeft ook de projectarchitect niet de absolute vrijheid om een oplossing te ontwerpen. De staande organisatie legt beperkingen op, verwoord in architectuurkaders, om te voorkomen dat het bedrijfsbelang ondergeschikt raakt aan projectbelangen. Zulke architectuurkaders horen al bekend te zijn voordat het project start. Als ze er niet of niet tijdig zijn dan heeft het project, in theorie, carte blanche om een oplossing te kiezen die het beste past. In de praktijk staan in zo’n geval op onverwachte momenten alsnog belanghebbenden op die de projectarchitectuur kunnen afwijzen. Dat kan leiden tot wijzigingen in de architectuur en het kan projectplannen in de war schoppen. Denk aan een security officer die blokkerende risico’s ziet of een beheerafdeling die aangeeft dat de nieuwe servertechnologie te laat beschikbaar zal zijn. Veel projectarchitecten kiezen er daarom voor om zelf de kaders op te halen waarbinnen ze moeten werken. Dat mondt al snel uit in een langdurig proces van informatie verzamelen, concepten schrijven en reviewrondes organiseren. Terwijl de architect daar zoet mee is, gaat de project- manager door met zijn plan van aanpak – hij heeft immers een deadline te halen. Daarmee richt hij zich al op de oplossing terwijl de architect nog bezig is de vraag te verkennen. Geen wonder dat er spanningen ontstaan. De projectarchitect bevindt zich op zo’n moment in een spagaat. Hij is medeverantwoordelijk voor het slagen van het project, maar tegelijkertijd wordt van hem verwacht dat hij optreedt als hoeder van de (overkoepelende) enterprise-architectuur. Een onmogelijke positie, omdat de belangen van de staande organisatie en die van het project lang niet altijd in elkaars verlengde liggen.

Twee principes

Om dit patroon te doorbreken, moet een aantal zaken goed geregeld worden. Ten eerste moet het proces worden afgesproken om een project op te starten. Op zijn minst moet dat proces mijlpalen definiëren met hun entry- en exitcriteria en wie daarvoor verantwoordelijk is. Duidelijk is dat de projectarchitect zijn handen vrij moet hebben om voor zijn project het best mogelijke resultaat te behalen. Regels en richtlijnen ophalen hoort niet bij zijn takenpakket: kaders worden gesteld aan het project, niet door het project. Wanneer een project wordt opgestart, hoort het die kaders direct mee te krijgen en vanaf dat moment moeten ze ook stabiel zijn: de spelregels mogen niet zomaar worden veranderd als het spel eenmaal is begonnen.

De architectuurkaders voor een project zijn vrijwel altijd gebaseerd op algemene regels en richtlijnen. Veel organisaties hebben zulke richtlijnen wel, maar ze zijn niet altijd opgeschreven en wat er wel op papier staat, is vaak verspreid over verschillende documenten die zich schuilhouden in een hoekje van het intranet of op een gedeelde harde schijf. Ze samenvoegen in een set basisregels en die centraal beschikbaar stellen, maakt duidelijk wat de afspraken zijn waaraan een project zich heeft te houden. Twee principes moeten leidend zijn bij het opstellen van zulke algemene architectuurkaders: ‘concreter is beter’ en ‘minder is meer’. ‘Concreter is beter’ wil zeggen dat direct toepasbare richtlijnen en vuistregels meer waard zijn dan vage principes. Bijvoorbeeld: we ondersteunen deze versies van MySQL en SQL Server als databases; met deze leveranciers werken we graag samen; in koppelingen met externe partijen gebruiken we protocollen X, Y en Z. Wie van zulke regels wil afwijken, moet toestemming vragen. Wie ze volgt, kan ongehinderd voortgaan.

Het aantal kaders beperken is belangrijk omdat concrete regels en richtlijnen altijd pijn doen. Door grenzen te stellen, beperkt de staande organisatie de vrijheid van het project om de beste oplossing te kiezen. Hoe ruimer de grenzen zijn, hoe groter de kans dat er een haalbare en maakbare oplossing gevonden wordt: minder kaders betekent meer vrijheid. Daarom moet de staande organisatie de verleiding weerstaan om het denkwerk van projecten over te nemen en moet zij alleen keuzes maken om hogere organisatiebelangen te bewaken.

Eén board

Om te voorkomen dat een project bij allerlei gremia en loketten om toestemming moet bedelen, moeten de verschillende belanghebbenden van de projectarchitectuur zoveel mogelijk worden samengebald. Laat een enkele board de belangen van bijvoorbeeld enterprisearchitectuur, beheer en het security office vertegenwoordigen. Een effectieve board houdt zich verre van peer reviews en inhoudelijk advies, maar toetst alleen aan de vooraf afgesproken kaders. Hij richt zijn aandacht met name op projecten die iets nieuws proberen of onvoorziene wegen inslaan. Dat zijn namelijk de projecten waarvan de organisatie kan leren en die kunnen leiden tot het radicaal verbeteren en aanvullen van de architectuurkaders. Door op deze manier de architectuur in de staande organisatie te scheiden van die in projecten wordt vertraging voorkomen en krijgen projecten de kans om te doen waar ze voor bedoeld zijn: snel en betaalbaar IT-oplossingen realiseren waar de staande organisatie mee uit de voeten kan.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google photo

Je reageert onder je Google account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s