Geef projectarchitect de ruimte

Geef projectarchitect de ruimte


10 maart 2016 - Bron: AutomatiseringGids

Projecten hebben een grotere kans van slagen als de projectmanagers en -architecten samen door één deur kunnen. De managers bemoeien zich te vaak met techniek en architecten zien te veel beren op de weg. Althans, dat is het beeld. Rob Berentsen en Eelco Rommes, senior adviseurs bij M&I/Partners, laten zien wat er nodig is voor een goede samenwerking. 'Concreter is beter' en 'minder is meer'.

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 (zie kader). 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. (zie: ‘Principeverslaving verzwakt architectuur’).

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.

Vier tips voor projectarchitecten

In veel organisaties worden projectarchitecten in een onmogelijke positie gedwongen: ze moeten de beste oplossing voor het project ontwerpen én het overkoepelende organisatiebelang bewaken. Keurig binnen de lijntjes blijven is niet altijd goed voor het project, maar teruggefloten worden door een architectuurboard is dat ook niet. Hoe ga je met die spanning om? Vier tips:

  1. Spreek vroeg in het project reviewmomenten af. Maak daarbij onderscheid tussen twee soorten reviewers: inhoudelijke experts helpen je om de oplossing te verbeteren, beslissers toetsen of het project verder mag. Maak eerst afspraken met de beslissers en vraag door totdat de norm die ze hanteren helder is: waaraan moet de oplossing voldoen?
  2. Zorg vervolgens dat de reviews met beslissers een formaliteit zijn: je wilt van tevoren zeker weten of je ontwerp wordt goedgekeurd. Beslissers laten zich in de regel adviseren door experts. Neem zowel experts als beslissers mee in het proces door regelmatig over je voortgang te overleggen en hun zorgen in acht te nemen.
  3. Ga nooit met lege handen zo’n overleg in. Maak zo snel mogelijk een eerste schets van de oplossing en gebruik die in de gesprekken met experts en beslissers. Juist omdat een schets nog lang niet af is, prikkel je anderen en bied je hun ruimte om invloed uit te oefenen, zodat ze mede-eigenaar worden van de gekozen oplossing. Die wordt daar niet alleen beter van, maar vooral beter verkoopbaar in de organisatie.
  4. Te veel projectarchitecten verstoppen zich tussen hun collega-architecten. Zorg dat je daar bent waar de architectuur gemaakt wordt. In het begin is het belangrijk om veel bij de projectmanager te zitten en samen te werken. Als de realisatie begint, verdeel je je tijd tussen het realisatieteam en de andere belanghebbenden. De echte IT-architectuur staat namelijk niet op papier of in modellen, die zit in het IT-systeem zelf.


Eelco Rommes

Senior adviseur
eelco.rommes@mxi.nl
06 53 30 39 72
Lees mijn publicaties