Managementduo: projectmanager en ICT-architect

Ieder ict-project van enige omvang zou feitelijk bestuurd moeten worden door een managementduo, bestaande uit een projectmanager en een architect. De eerste gaat over tijd, geld, mensen, planning en inzet van andere middelen en is de spreekbuis van het project. De architect is verantwoordelijk voor het inhoudelijke resultaat, een werkende oplossing die voldoet aan de eisen en wensen van de opdrachtgever/klant, dat past binnen de bestaande architectuur. Hieruit is af te leiden dat beide tot elkaar en vroegtijdig tot goede samenwerking veroordeeld zijn.

Veel organisaties in Nederland gebruiken inmiddels de projectmethodiek Prince2 of een andere methodiek en schakelen een projectmanager op zodra een projectvoorstel is goedgekeurd. Deze begint, afhankelijk van de omvang van het project aan een projectbrief (plan van aanpak) of aan een projectinitiatiedocument (PID). In deze aanloop naar het project komt de onderzoeksfase voor waarin de business case wordt opgesteld. In veel gevallen echter wordt de architect pas opgeschakeld in de eerste uitvoeringsfase van het project, bijvoorbeeld de ontwerpfase, terwijl het zinvol is om juist in de onderzoeksfase al gebruik te maken van de ict-architect.

Stakeholderanalyse en -spel

Door de architect vroeg te betrekken kan de projectmanager gebruikmaken van de brede inzichten van een architect en kan de architect meteen al deelnemen aan het voorbereiden van het project, zoals het opstellen van de lijst met belanghebbenden en hun belangen en de business case. Zowel projectmanager als architect hebben veel belang bij de lijst belanghebbenden (stakeholders), gedeeltelijk ieder om hun eigen redenen, maar voor een deel ook overlappend. Zo zal het voor de projectmanager erg handig zijn om te bepalen wie veel invloed op het project hebben, met wie veel contact onderhouden moet worden en wie over wat gaat als het op belangrijke beslissingen aan komt.

De architect daarentegen legt in deze fase de eerste inzichten aan met betrekking tot de eisen en wensen van de belanghebbenden en de perspectieven die hij later daarop moet ontwikkelen. Voor beide geldt dat al vroegtijdig een beter beeld ontwikkeld wordt waar de uitdagingen in het project zullen zitten, welke expertise nodig zal zij, en hoe de business case moet worden aangevlogen. In deze onderzoeksfase stelt de (project) architect ook de Project Start Architectuur (PSA) op in overleg met de enterprise architectuur. De PSA is niet een beschrijving van de oplossing, maar een set van relevante kaders en standaarden vanuit de enterprise architectuur die worden meegegeven aan het project.

Inzichten in planning en kosten

In dit samenspel tussen projectmanager en architect ontstaan inzichten en daarmee kunnen de projectdefinitie, de projectdoelstelling, veel beter geschreven worden en kunnen de resultaten scherper worden aangegeven dan wanneer de projectmanager dit alleen zou moeten doen. Omdat een architect meer feeling heeft met de inhoudelijke kant kan hij de projectmanager ondersteunen bij het inschatten van hoeveelheden werk en daarmee een belangrijke bijdrage leveren aan geschatte benodigde tijd per expertise, de projectplanning en de geschatte kosten.

Zonder een architect op te schakelen, of te laat, zal er wellicht eerder een projectbrief/PID op tafel liggen, maar begint de architect met een achterstand en vaak met een heleboel vragen die het project soms weer in tijd terug plaatsen omdat daar niet over nagedacht was, of een aanpassing in business case of projectplanning noodzakelijk wordt. Dit is slechts gedeeltelijk op te lossen door een requirementsfase aan de ontwerpfase vooraf te laten gaan in de projectplanning.

Project van start

Nadat de opdrachtgever op basis van de projectbrief en/of het PID een 'go' heeft gegeven, kan het managementduo aan de slag met het uitvoeren van het project. De stakeholders worden bijeengebracht voor een of meerdere workshops, afhankelijk van de grootte en/of complexiteit van het project. Doordat de stakeholderanalyse al gemaakt is kan de architect snel en doelmatig van start met het verzamelen van de eisen en wensen (requirements), waarbij de meest invloedrijke stakeholders aan de businesszijde het eerst gehoord worden en vervolgens afgedaald wordt naar proces-, gegevens- (informatie-) en applicatie-architectuur en als sluitstuk de technische architectuur.

Op basis van deze informatie en met de kaders van de PSA kan de projectarchitect de Solution Architectuur opstellen, soms ook wel globaal ontwerp genoemd. De SA moet richting geven aan de technisch ontwerpen die volgen in de volgende fase. Met de SA definieert de solution architect een werkende oplossing die tegemoet komt aan de eisen en wensen zoals die gesteld zijn, met de beperkingen en aannames die daar uit voortvloeien. Met deze informatie adviseert de architect de projectmanager omtrent werkpakketten voor consultants en engineers, meer gedetailleerde planning en doorlooptijd en kosten van de volgende fase: de ontwerpfase.

Definiëren van de oplossing

De projectmanager alloceert de mensen met de gespecificeerde expertise en zorgt ervoor dat die beschikbaar zijn op het juiste moment. Hij bewaakt verder voortdurend de planning, de kosten en de communicatie met de stakeholders. (Technische) Ontwerpers krijgen de ruimte om de oplossing gestalte te geven binnen de kaders die de architect gezet heeft. De architect ziet in de ontwerpfase door middel van reviews er op toe dat de technische ontwerpen voldoen aan de gestelde eisen. De architect blijft eindverantwoordelijk voor de geboden oplossing.

Bij tussentijdse veranderingen en/of bijsturingen in het project geeft de architect een inhoudelijk advies aan de projectmanager dat deze vrijwel altijd dient op te volgen en op gepaste wijze te communiceren aan belanghebbenden. Het is vaak verleidelijk voor een projectmanager om hier van af te wijken en de kosten en tijd van de architect te besparen. Daarmee wordt echter de kans vergroot dat het project afwijkt van de standaarden, uitgangspunten en aannames en de PSA die een inhoudelijk verantwoordelijk architect nastreeft en wordt met een succesvol project feitelijk een sub-optimum resultaat bereikt voor de organisatie.

Implementatie en oplevering

Na de ontwerpfase zal de architect veel minder nodig zijn en gaat de projectmanager over tot de implementatiefase en uiteindelijk de oplevering na adequaat testen. Voor de oplevering zal de projectarchitect betrokken worden om te verifiëren dat de oplossing bereikt is die hij voor ogen had en kan de Project Eind Architectuur worden opgeleverd (dit is de PSA met alle bijgewerkte changes gedurende het project) en in samenwerking met de enterprise architect worden afgetikt.

Gedurende het project is de architect de inhoudelijk verantwoordelijke en adviseert hij voortdurend de projectmanager over te nemen inhoudelijke beslissingen. De architect is primair verantwoordelijk voor een werkende, kwalitatieve oplossing die voldoet aan de vraag van de klant en binnen opgelegde kaders blijft. De projectmanager is geslaagd als hij het project binnen de overeengekomen kaders van tijd en geld kan laten opleveren. Uit bovenstaande is duidelijk af te leiden dat beide tot elkaar en vroegtijdig tot goede samenwerking veroordeeld zijn.

Ing. Vincent AWG Jansen
MSc IT Architecture