Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Managementduo: projectmanager en ICT-architect

 

Expert

ing. Vincent Jansen MSc
Architect ICT Infrastructuur, Hewlett-Packard Enterprise. Expert van voor het topic .

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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3303093). © Jaarbeurs IT Media.

?


Sponsored

 

Reacties

Goede beschrijving van een architectuur raamwerk. Waar ik het vaak 'zie wringen' is dat 'inhoudelijke advies dat meestal opgevolgd dient te worden' onder druk nu precies niet opgevolgd wordt. Dit heeft te maken met het laatste taboe : macht. Voor goede resultaten is een gelijkwaardige relatie nodig tussen architect en programmamanager. Echter, de skills van een programmamanager zijn vooral gericht op het onderhandelen (lees tevreden houden van de verschillende stakeholders). Terwijl die van een architect inhoudelijk van aard is. De relatie is dus per definitie niet gelijkwaardig, was het maar omdat aan macht een grotere maatschappelijk waarde wordt toegekend als aan inhoud. De besluiten die in dit scenario onder deze omstandigheden genomen worden, zijn naar mijn mening DE oorzaak waarom er zoveel (IT) projecten falen c.q. niet het gewenste optimale resultaat opleveren. Je kunt het ook anders lezen : de architect wordt op deze manier behandeld als 1 van de stakeholders waarvan de concerns uitgeruild kan worden....

Het is al weer even geleden dat ik Prince 2 Foundation heb gehaald, maar nergens kon ik me herinneren dat er fases als 'Ontwerp', 'Implementatie','Test' en 'Oplevering' zijn.
Is het mogelijk op voorhand bij ontwikkelen van software alle requirements boven tafel te krijgen? Kun je wel spreken van scheiding tussen Ontwerp en Implementatie bij softwareontwikkeling?
Ontwerp, Implementatie, Test en Oplevering zou ook best in iedere fase uitgevoerd worden. Niets in Prince 2 sluit dit uit. Voordeel is dat de architect, alsmede andere betrokkenen, veel beter met nieuwe inzichten kunnen omgaan.

Veel zaken die open deuren zouden moeten zijn. Maar helaas maar zelden zijn; oftewel Hulde.

Wellicht een gedachte om deze rol expliciet te maken als 'project architect'.

Chappeau! Ik had het zelf geschreven kunnen hebben. Een uitstekende beschrijving van de werkverdeling die naar mijn ervaring in de praktijk uitstekend werkt!

En nu test nog.

Een belangrijke reden dat (project-)architect en (project-)manager vaak tot elkaar veroordeeld zijn is dat er veel kruisverbanden tussen hun verantwoordelijkheden bestaan. Zo wordt een PM vaak verantwoordelijk gemaakt voor het voortbrengingsproces en de architect voor het realiseren van de requirements, inclusief kwaliteitsattributen als security en robuustheid. Kwaliteitseisen (soms NFRs of Non-Functional Requirements genoemd) impliceren echter vaak eisen aan het voortbrenginsproces. Dus de PM moet maatregelen nemen om de verantwoordelijkheid van de architect te kunnen vervullen, en andersom.

In het algemeen is een te strenge scheiding van sturing en inhoud sowieso contraproductief. Het is een cultureel verschijnsel dat het succes van organisaties soms danig in de weg zit. Zie ook de intensieve menshouderij: www.intensievemenshouderij.nl.

Een hele mooie en goede bijdrage. Sluit zeker aan met mijn gedachtegoed/werkwijze.
Om echt beoogde resultaten te boeken zou ik nog een derde functie willen toevoegen gedurende het project. De uitvoerende techneut (of teamleider bij meerdere specialismen). Net als bij financiële omgevingen zijn er altijd 3 mensen nodig om resultaten te bereiken. Ook in juridische omgevingen spreken we over trias politica....
Zouden we met IT toch bijna volwassen professionals zijn??

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.