WHITE PAPER PRINCE2 EN ARCHITECTUUR

Transcriptie

1 WHITE PAPER PRINCE2 EN ARCHITECTUUR JOOST LUIJPERS

2

3 WHITE PAPER PRINCE2 EN ARCHITECTUUR Joost Luijpers Versie: Copyright te Vianen Niets uit deze uitgave mag worden verveelvoudigd (voor willekeurig welke doeleinden) door middel van druk, fotokopie, microfilm, geluidsband, elektronisch of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van I

4

5 Whitepaper: Prince2 en Architectuur Reviewers REVIEWERS De volgende medewerkers van Sogeti hebben bijgedragen aan de totstandkoming van deze white paper: Naam Martin van den Berg Paul Dijkwel Hans Engelen Harmen Holwerda Henk Jumelet Aniel Kalicharan Krijn Kalma Cor Kingma Rudy Kusse Han Streithorst Maarten van der Werff Renzo Wouters Functie Management Consultant Senior Program Manager Program Director manager Informatie architect Informatie architect manager manager Informatie architect manager Informatie architect Informatie architect 1

6 Whitepaper: Prince2 en Architectuur INHOUDSOPGAVE REVIEWERS... 1 INHOUDSOPGAVE INLEIDING... 1 Doel van het document Doelgroep Opzet van het document Verwachte voorkennis ARCHITECTUUR EN PROJECTEN DYA in een notendop Het DYA-model Het architectuurraamwerk Architectuur en projecten architect Controlling architect Escalatie naar de architectuurraad PRINCE2 EN ARCHITECTUUR Overzicht relatie Prince2 en architectuur Opstarten project (OP) OP4 voorstel opstellen OP5 aanpak definiëren OP6 Plannen Initiatiefase Initiëren project (IP) IP1 Kwaliteitsplan opstellen IP3 Business case & Risico s aanscherpen IP4 beheersing opzetten Sturen (SP) SP1 initiatie autoriseren SP4 - Ad hoc sturing geven SP5 - afsluiting bevestigen Beheersen Fase (BF) BF3 - issues verzamelen BF4 - issues beoordelen BF8 - issues escaleren BF9 - Afgerond Werkpakket ontvangen

7 Whitepaper: Prince2 en Architectuur Inhoudsopgave 3.6 productoplevering (MP) MP1 - Werkpakket aannemen MP2 - Werkpakket uitvoeren faseovergangen (MF) MF1 Faseplan opstellen MF3 Business case actualiseren MF6 Afwijkingsplan opstellen Afsluiten project (AP) AP1 afbouwen AP2 Vervolgacties identificeren Opstellen plan (PL) PL2 - Producten definiëren en analyseren PL3 - Activiteiten en afhankelijkheden identificeren PL4 - Schatting maken PL5 - Tijdschema opstellen THEMA S MET ARCHITECTUUR BINNEN PROJECTEN Inrichting van het project Impact Analyse Kwaliteit PSA Afwijkingen n op de architectuur

8

9 Prince2 en Architectuur Inleiding 1 INLEIDING Veel organisaties hebben ervoor gekozen om Prince2 als projectmanagementmethode te hanteren. Wanneer een organisatie daarnaast onder architectuur gaat werken, betekent dit dat er ook onder architectuur ontwikkeld gaat worden. Aangezien de meeste ontwikkelingen (lees: veranderingen) projectmatig worden doorgevoerd, zal architectuur ook terug te vinden zijn in de werkwijze van het uitvoeren van projecten en de producten die het project oplevert. Doel van het document Het doel van dit document is om te beschrijven hoe het werken onder architectuur volgens DYA het werken met Prince2 1 raakt en beïnvloedt. Het aanhaken van architectuur op Prince2 kent vier vormen: Een binnen Prince2 bestaande activiteit (of een onderdeel daarvan) krijgt een extra dimensie vanuit architectuur; Aan een binnen Prince2 bestaande activiteit of product wordt een nieuw element vanuit architectuur toegevoegd; Aan een binnen Prince2 bestaande activiteit of product wordt vanuit architectuur een bijdrage geleverd; Vanuit de architectuur worden andere standaardproducten toegevoegd. De beschrijving in dit document van de relatie tussen Prince2 en architectuur geeft aan waar van één van deze vier aanpassingen sprake is op het moment dat een project dat met Prince2 wordt gedaan onder architectuur wordt uitgevoerd. Bij een beschrijving van de relatie tussen Prince2 en architectuur komt automatisch de relatie tussen projectleiders 2 en architecten 3 tot uitdrukking. Het is ook het doel van dit document om deze relatie duidelijk te maken. De beschrijving geeft aan waar deze twee spelers elkaar binnen een project tegen komen. 1.2 Doelgroep De doelgroep voor dit document zijn de projectleiders enerzijds en de architecten 4 anderzijds. Voor projectleiders wordt duidelijk op welke manier architectuur inhaakt op de uitvoering project. Er wordt beschreven op welke plek, vanuit de procesgang van Prince2 de vier soorten van verandering, zoals hierboven aangegeven, plaatsvinden. Daarbij wordt ook duidelijk welke acties van hen verwacht worden en welke zij van de architecten kunnen verwachten. Zij kunnen dus aan de hand van dit document hun projectplan en -aanpak inclusief architectuur uitwerken. De architecten krijgen inzicht op welke plaats en manier hun werkzaamheden ten behoeve project inhaken op de aansturing van dat project. 1 De kennis over Prince2 is ontleend aan het boek De essentie van Prince2, geschreven door Colin Bentley, ISBN Dit boek is eigendom van Key Result. 2 Wanneer in dit document de term projectleider wordt gehanteerd, wordt hiermee ook projectmanager bedoeld, tenzij expliciet anders aangegeven. 3 Er bestaan veel verschillende functiebenamingen voor architecten. De algemene term architect wordt gebruikt wanneer elk van deze bedoeld worden. Specifieke soorten architecten worden expliciet aangegeven. 4 Bij veel organisaties wordt de term Informatiemanager gehanteerd. Deze worden hier ook bedoeld. 1

10 Whitepaper: Prince2 en Architectuur Inleiding 1.3 Opzet van het document In hoofdstuk 2 worden de essenties van DYA in het kort geschetst en wordt een globale schets gegeven van de relatie tussen projecten en architectuur. Deze relatie komt in DYA-termen tot uitdrukking in het proces Ontwikkelen onder Architectuur. In hoofdstuk 3 en 4 staat inhoudelijk hetzelfde, maar vanuit een ander perspectief. In hoofdstuk 3 wordt het perspectief vanuit de processen van Prince2 gegeven. Dit hoofdstuk is in eerste instantie bedoeld voor lezers die bekend zijn en een affiniteit hebben met Prince2. Er wordt expliciet ingegaan op de uitgangspunten en voorschriften van Prince2 en de aanpassingen ngen die daarop van toepassing zijn nu er onder architectuur ontwikkeld wordt. Uitgangspunt zijn daarbij de processen zoals Prince2 die definieert. Prince2 wordt bekend verondersteld dus er wordt op die plaats verder geen beschrijving van Prince2 gegeven. Enkel wordt aangegeven wat de consequenties zijn van het werken onder architectuur. Hoofdstuk 4 is geschreven vanuit het architectuurperspectief. Dit hoofdstuk is in eerste instantie bedoeld voor lezers die bekend zijn en affiniteit hebben met architectuur. tuur. Vanuit architectuur is er een aantal thema's te onderkennen die gerelateerd zijn aan het uitvoeren van projecten. Hoofdstuk 4 beschrijft het aanhaken op Prince2 vanuit dat perspectief. 1.4 Verwachte voorkennis Van de lezers van deze white paper wordt verwacht dat zij enige kennis hebben van zowel Prince2 als DYA. Binnen DYA is met name de PSA van belang. Deze kennis is te verkrijgen door het bestuderen van de onderstaande publicaties. Zoals in paragraaf 1.3 is aangegeven wordt DYA in hoofdstuk 2 in een notendop beschreven. [1] De essentie van Prince2 ; Colin Bentley; ISBN Dit boek is eigendom van Key Result. [2] De kleine Prince 2, vierde gehele herziene editie; Mark van Onna, Ans Koning; Academic Service; ISBN [3] DYA : Snelheid en samenhang in business- en informatiearchitectuur, derde oplage, augustus 2002; Roel Wagter, Martin van den Berg, Joost Luijpers, Marlies van Steenbergen; Uitgeverij Tutein Nolthenius, Den Bosch 2001, Nederland; ISBN ; 4; [4] DYA : Stap voor stap naar professionele enterprise-architectuur, 2004; Martin van den Berg, Marlies van Steenbergen; Ten Hagen & Stam uitgevers; ISBN [5] Start Architectuur, 2007 White paper; Joost Luijpers; [6] DYA INfrastructuur, architectuur voor de fundering van de IT, 2007; Daniel Jumelet; Academic Service; ISBN: /

11 Prince2 en Architectuur Architectuur en projecten 2 ARCHITECTUUR EN PROJECTEN 2.1 DYA in een notendop In deze paragraaf wordt DYA in een notendop beschreven. Meer informatie is te vinden in [3] en [4] en op DYA is de visie van Sogeti op het omgaan met architectuur. Het gaat over de totstandkoming en het onderhouden van de architectuur. Dit moet op een dynamische manier plaatsvinden; de organisatie gaat op een slimme, slanke en snelle wijze om met het fenomeen architectuur. DYA is ontstaan op basis van ervaringen uit de praktijk over hoe met architectuur wordt omgegaan. DYA is gefundeerd op tien principes. Deze principes worden door onderstaande uitgangspunten samengevat: Architectuur is geen doel op zich, maar is ondersteunend aan de doelen die de organisatie wil bereiken. Het doel van architectuur is niet om een document op te leveren, maar om ervoor te zorgen dat de veranderprocessen van de organisatie steeds soepeler gaan verlopen. Architectuurontwikkeling moet daarom worden verankerd in die veranderprocessen. Architectuur kan heel goed stukje bij beetje worden aangepakt. Het is niet nodig om in één keer een volledig architectuurdocument neer te leggen. Architectuur evolueert mee met de organisatie. Afwijken van de architectuur kan onder omstandigheden noodzakelijk zijn. Het is wel zaak een mechanisme in te richten waarmee dergelijke afwijkingen van de architectuur worden beheerst. Dit kan door aparte ontwikkelscenario's te onderscheiden voor het ontwikkelen onder architectuur en voor het niet volledig onder architectuur ontwikkelen. 2. Het DYA-model De kern van DYA wordt gevormd door het DYA-model. Figuur 1 toont het DYA-model. Dit model bevat vier processen die het hele traject van strategievorming tot realisatie beslaan. Deze processen helpen om uw architectuur in te richten, zodat tot een inzet van ICT wordt gekomen waarbij de business slagvaardig wordt bediend tegen acceptabele kosten. De samenhang tussen businessarchitectuur, informatiearchitectuur en technische architectuur wordt daarbij gewaarborgd. Inrichten van de processen rondom architectuur conform DYA heeft het voordeel dat de momenten zijn vastgelegd waarop architecturen gemaakt en toegepast worden. Daardoor is bekend op welk moment een architect nodig is en wat hij dan oplevert. Resultaat is de juiste architectuur op het juiste moment. 3

12 Whitepaper: Prince2 en Architectuur Architectuur en projecten Figuur 1 Het DYA-model In de Strategische Dialoog worden, op basis van de business strategie de businessdoelen bepaald, die vervolgens in business cases worden uitgewerkt tot concrete projectvoorstellen. Gezien het strategische belang van ICT tegenwoordig voor een organisatie bepalen business- en ICT-management steeds meer samen welke businessdoelen de organisatie wil nastreven. De mogelijkheden binnen de ICT bepalen namelijk mede de mogelijkheden voor de organisatie. Deze businessdoelen worden vervolgens in multidisciplinaire teams uitgewerkt tot business cases. De business cases geven aan hoe het gewenste doel bereikt kan worden, wat dat voor de organisatie betekent (op basis van impact analyses) en wat de financiële consequenties zijn (in termen van investering, jaarlijkse kosten en baten). Is een business case positief, dan wordt overgegaan tot het opstellen concreet projectvoorstel. De uitkomst van deze activiteiten is het projectportfolio; het overzicht welke projecten uitgevoerd (gaan) worden. Vanwege de directe relatie die dit portfolio heeft met de strategische doelen van de organisatie, zijn de functionarissen die bij de Strategische Dialoog betrokken zijn ook betrokken bij het projectportfoliomanagement. Zowel bij het vaststellen van de businessdoelen als bij het uitwerken van business cases werken business en ICT nauw samen. Het doel van de Strategische Dialoog is te zorgen dat op tijd de juiste dingen gedaan worden. Ontwikkelen (z)onder Architectuur realiseert de concrete businessdoelstellingen, binnen de gewenste doorlooptijd met de gewenste kwaliteit en tegen acceptabele kosten. Bij dit proces gaat het dus om de projectuitvoering. Hierbij is het ontwikkelen onder architectuur de standaard. Bij Ontwikkelen onder Architectuur krijgt het projectteam een zogenaamde projectarchitectuur is een vertaling van de algemene architectuurprincipes en modellen naar een op het project toegesneden start-architectuur architectuur mee. Een project-start-architectuur kader. Dit kader geeft de concrete standaarden, normen en richtlijnen weer die het project zal hanteren. Ook projectoverstijgende ontwerpkeuzen worden in de project- 4

13 Prince2 en Architectuur Architectuur en projecten start-architectuur vastgelegd. De project-start-architectuur wordt door de architecten opgesteld, in nauwe samenwerking met het projectteam. In paragraaf 2.2 wordt hier dieper op ingegaan. Onder speciale omstandigheden, echter, wanneer er sprake is van extreme tijdsdruk, kan er voor gekozen worden om voor een keer bewust niet onder architectuur te ontwikkelen. Dan wordt het proces Ontwikkelen zonder Architectuur uitgevoerd. In dit proces worden op beheerste wijze bepaalde architectuuraspecten tijdelijk niet meegenomen. Op beheerste wijze, omdat gelijktijdig, via de zogenaamde management letter, maatregelen genomen worden om uiteindelijk wel weer onder architectuur te komen. De management letter is een "contract" tussen opdrachtgever, projectmanager en architect waarin afspraken worden gemaakt met betrekking tot de beperkte levensduur van het projectresultaat en het parallel starten structureel traject. Het doel van Ontwikkelen (z)onder Architectuur is de juiste dingen juist doen. In dit model is Architectuur Services, het opstellen en bewaken van de architectuur, duidelijk gepositioneerd als ondersteunend proces. Architectuur is geen doel op zich, maar een middel om de veranderingen, vormgegeven in de Strategische Dialoog en het Ontwikkelen (z)onder Architectuur, zodanig te sturen dat de businessdoelen optimaal bediend worden. Architectuur Services is faciliterend aan de Strategische Dialoog en Ontwikkelen onder Architectuur. Het proces slaat daarmee de brug tussen de businessdoelen en de projecten die de oplossingen leveren. Aan de Strategische Dialoog worden de benodigde architectuurprincipes en modellen, onderdeel van de Referentie Architectuur 5, geleverd ten behoeve van het uitwerken van de business cases. Tevens helpt dit proces met het uitvoeren van de impact analyses. Ontwikkelen onder Architectuur wordt ondersteund met concrete kaders, richtlijnen, hulpmiddelen en ontwerpkeuzen in de vorm project-start-architectuur. De trigger voor Architectuur Services is doorgaans een concrete business case die uitgewerkt moet worden. Het doel van Architectuur Services is te zorgen dat de dingen juist gedaan worden. Processen lopen niet vanzelf goed. Daarvoor is een vorm van besturing nodig. Verantwoordelijkheden moeten duidelijk belegd zijn en er moet bewaakt worden dat de gewenste resultaten bereikt worden. Daarbij is het belangrijk de juiste stuurinstrumenten ter beschikking te hebben. Topmanagement speelt hierin een heel belangrijke rol. De eindverantwoordelijkheid voor architectuur is ook een zaak van het topmanagement. Wij vatten de besturingsaspecten samen onder de term governance. Een dynamische architectuur is een architectuur die specifiek gericht is op snelheid. Hier zitten twee kanten aan. In de eerste plaats is er de inhoudelijke kant die slaat op de architectuur als product: de vorm van de architectuur is zodanig dat aanpassingen aan nieuwe, nu nog onvoorziene, ontwikkelingen zo snel en goedkoop mogelijk zijn. De architectuur kan wijzigingen in de bedrijfsvoering snel ondersteunen. Hierbij spelen zaken een rol als ontkoppelpunten, gegevens bij de bron halen, sturing op interfaces en scheiding van presentatie-, business- en datalaag. De tweede kant is de proceskant: het omgaan met architectuur. Hier wordt mee bedoeld dat het tot stand komen en onderhouden van de architectuur dynamisch is. 5 De Referentie Architectuur geeft de principes, richtlijnen en standaarden weer die bij toekomstige ontwikkleingen gehanteerd moeten worden. Deze zijn gebaseerd op een ideale weergave van de toekomstige situatie, waar de verschillende ontwikkelingen naartoe moeten werken. Deze schets van de toekomstige situatie is ook een onderdeel van de Referentie Architectuur. Daarnaast kan de Referentie Architectuur een weergave van de huidige situatie bevatten. 5

14 Whitepaper: Prince2 en Architectuur Architectuur en projecten De organisatie gaat op een slimme, slanke en snelle wijze om met het fenomeen architectuur. Hierbij spelen zaken een rol als multidisciplinaire samenwerking, just-in-time architectuur, just-enough architectuur en de project-start-architectuur. architectuur Het architectuurraamwerk Om de architecturen te kunnen classificeren heeft DYA zijn eigen architectuurraamwerk. Het vormt als het ware een ladenkast waarin elke architectuur zijn plek krijgt. Het architectuurraamwerk illustreert dat de architectuur organisatie niet als een monolithisch geheel beschouwd moet worden, maar opgedeeld in onderdelen. Sommige van die onderdelen zullen in een specifiek geval tot in detail zijn uitgewerkt (de cel in de matrix is gevuld), terwijl andere delen wellicht nog helemaal niet beschouwd zijn (de cel is nog leeg). Dat is volstrekt legitiem. Zolang de wel ingevulde delen maar consistent met elkaar, en met de businessdoelen, zijn en de delen zijn ingevuld die nodig zijn voor de sturing van de actuele veranderingen binnen de organisatie. Het Architectuurraamwerk van DYA, zoals hieronder in Figuur 2 afgebeeld, heeft als doel om relevante deelarchitecturen turen een plek te kunnen geven en verbanden tussen deelarchitecturen zichtbaar te maken. De horizontale as van het raamwerk geeft de verschillende objecten van architectuur weer in de veelvoorkomende driedeling businessarchitectuur, informatiearchitectuur en technische architectuur. Deze driedeling wordt door vele architecten herkend. Daarbinnen is nog een verdere opdeling te maken. Elk van deze architecturen heeft een ander object van architectuur (producten/diensten, processen, gegevens, storage, etc.). Voor elk van deze objecten onderscheidt het raamwerk een kolom. De businessarchitectuur vormt het kader voor de wijze waarop de organisatie georganiseerd is om de businessdoelen te bereiken: de producten en diensten waarmee de organisatie de bedrijfsdoelen wil bereiken, de processen die hiervoor nodig zijn en de manier waarop de uitvoering van die processen is georganiseerd. De informatiearchitectuur vormt het kader voor de wijze waarop de informatievoorziening binnen de organisatie vorm gegeven wordt: de gegevens die voor de organisatie van belang zijn en de applicaties waarmee de informatie- uitwisseling binnen de organisatie ondersteund wordt. De technische architectuur vormt het kader voor de technische infrastructuur van de organisatie 6 : de servers die de procesverwerkende capaciteiten leveren, de middleware die ondersteunende, generieke ondersteuning aan bedrijfsapplicaties verzorgen, storage voor de (semi-)permanente opslag van data, de netwerken voor het transport van deze data tussen de verschillende systemen en de client realm voor het werkgebied van de gebruiker (inclusief werkstations en printers). Meer over deze indeling en de achterliggende uitwerking is te vinden in [6]. 6 Figuur 2 toont de oorspronkelijke indeling zoals die bij de introductie van DYA gehanteerd werd. [6] geeft een uitbreiding hierop. Een organisatie kan het raamwerk gebruiken dat voor hen het meest geschikt is. 6

15 Prince2 en Architectuur Architectuur en projecten Figuur 2 Architectuurraamwerk De verticale as van het raamwerk laat zien dat architectuur opgedeeld kan worden in drie abstractieniveaus: Algemene principes, Beleidslijnen en Modellen. Het hoogste abstractieniveau van architectuur is het niveau van de algemene principes. Deze weerspiegelen de gezamenlijke visie van business- en ICTtopmanagement. De algemene principes gelden voor iedereen en moeten ook voor iedereen begrijpelijk zijn. De algemene principes en concrete beleidslijnen samen noemen we de architectuurprincipes. Voorbeelden van algemene principes zijn: De organisatie streeft naar een foutloze en betrouwbare uitvoering van de dienstverlening; De klant kan bij één loket terecht voor al zijn vragen; Er mag geen ongeautoriseerde toegang plaatsvinden tot enig eigendom van de organisatie. Het tweede abstractieniveau van architectuur is het niveau van de concrete beleidslijnen die vorm geven aan de algemene principes. Deze zijn vaak specialistischer dan de algemene principes. Het is de vertaling van de algemene principes naar de concrete uitwerking per deelarchitectuur. Standaarden en richtlijnen bevinden zich bijvoorbeeld op dit niveau. De algemene principes en concrete beleidslijnen samen noemen we de architectuurprincipes. Voorbeelden van beleidslijnen zijn: Processtappen worden continu bewaakt op efficiency en tijdigheid van uitvoering; Processtappen zijn volledig traceerbaar; De loketmedewerkers zijn breed opgeleid; Toegang tot het netwerk kan alleen verkregen worden via een inlogprocedure; Wachtwoorden mogen niet langer dan 30 dagen geldig zijn. Het derde abstractieniveau van architectuur is het niveau van de specifieke modellen. Deze hebben, afhankelijk van het object van architectuur, verschillende vormen. Hier 7

16 Whitepaper: Prince2 en Architectuur Architectuur en projecten speelt de grafische vormgeving vaak een grote rol. De modellen vormen over het algemeen specialistentaal. Voorbeelden van modellen zijn: Organogram; Procesmodel; Gegevensmodel; Applicatie landschap; Netwerk lay-out. Het is zeker niet de bedoeling om in een autonoom proces het raamwerk van links naar rechts en van boven naar beneden cel voor cel in te vullen. Dat zou niet meer dan een papieren tijger opleveren. Integendeel, het raamwerk is juist bedoeld om de architect de mogelijkheid te bieden om zich bij het opstellen van architectuur te beperken tot specifieke onderdelen, terwijl hij toch het totaalbeeld bewaart. Welke cellen relevant zijn voor een organisatie hangt geheel af van de situatie en doelstellingen van de organisatie. 2.2 Architectuur en projecten en worden uitgevoerd om veranderingen door te voeren. Deze veranderingen echter, staan niet op zichzelf, maar passen in een groter geheel. Dat geheel wordt gevormd door de richting waarin de organisatie zich wilt ontwikkelen. Uiteindelijk zijn deze veranderingen bedoeld om de strategie die de betreffende organisatie voorstaat te realiseren. Het doel van architectuur is om het toekomstbeeld te schetsen waar alle veranderingen naartoe moeten werken. Dit volgt vanuit de strategie van de organisatie. In de uitvoering van de veranderingstrajecten gebruikt architectuur dat overzicht om te bewaken dat de ene verandering goed aansluit bij de andere veranderingen. Anders gezegd, architectuur heeft een helicopterview. De aanname is hierbij dat het doorvoeren strategie een langere termijn perspectief heeft. Het doorvoeren en bestendigen strategie is een kwestie van enkele jaren. en streven doorgaans kortere termijn doelen na. Kortom, het verschil tussen architectuur en projecten is de scope (respectievelijk breder tegenover smaller) en de termijn (respectievelijk langer tegenover korter). Werken onder architectuur betekent voor projecten dus dat de kortere termijn doelstelling voor het ene probleemgebied wordt afgestemd met de bedrijfsbrede context voor de langere termijn. Eén van de consequenties van het werken onder architectuur is dat aan een project extra requirements meegegeven worden vanuit de architectuur, ter bewaking van die langere termijn en om ervoor te zorgen dat de deeloplossing die het project oplevert past in het grotere geheel. Deze architectuurrequirements gaan over niet-functionele aspecten. Dit zijn extra requirements ter aanvulling op de gebruikelijke drieluik van requirements: business-, user- en systemrequirements. Figuur 3 geeft dit schematisch weer. 8

17 Prince2 en Architectuur Architectuur en projecten Algemene requirements Referentie Architectuur Principes en modellen Principes en modellen toegespitst op project Architectuur requirements Lange(re) termijn Korte termijn specifieke requirements Oplossing Impact analyse architect Figuur 3 Relatie architectuur en projecten Om de afstemming tussen het architectuurperspectief en het projectperspectief te krijgen wordt aan elk project de rol 7 van architect toegewezen. Deze projectarchitect ziet erop toe dat de resultaten van het project voldoen aan deze extra architectuurrequirements. Aan het begin van het project stelt hij deze architectuurrequirements op. Hierbij gaat het om het afleiden van requirements voor het project op basis van de Referentie Architectuur. Tijdens het project begeleidt hij het projectteam bij het maken van de juiste keuzes vanuit het gezichtspunt van de langere termijn en het grotere geheel. Als het project is afgelopen borgt hij de resultaten van dat project in de Referentie Architectuur. Dit betekent dat het overzicht van de huidige stand van zaken wordt aangepast en dat eventueel bestaande kaders worden aangepast, vervangen of verwijderd Controlling architect Een andere rol 8 die vanuit de architectuur aan een project wordt toegevoegd is die van de controlling architect. Tijdens het project controleert hij de verschillende producten die door het project worden opgeleverd op het voldoen aan de architectuurrequirements. Hiertoe neemt hij deel aan de productreviews. Hij is geen integraal onderdeel van het projectteam. Omwille van de zuiverheid van zijn oordeel dient de rol van de controlling architect door iemand anders ingevuld te worden dan degene die het product heeft opgesteld. Ontwerpdocumenten zijn in principe het product van de ontwerper. De projectarchitect kan dan ook de rol van de controlling architect op zich nemen. Indien de betrokkenheid van de projectarchitect bij het opstellen van het ontwerpdocument dusdanig is geweest dat dit product ook als zijn eigendom beschouwd kan worden, kan een andere architect de rol van de controlling architect vervullen. In het vervolg van het document wordt de rol van de controlling architect expliciet benoemd als onderscheiden van de rol van de projectarchitect. Wanneer beide rollen door de zelfde functionaris worden vervuld, vervalt dus dat onderscheid. 7 architect is een rol, geen functie. Deze rol kan dus door verschillende functionarissen ingevuld worden, zoals architecten van allerlei soorten en maten. De aard van het project bepaalt mede welke functionaris hier het meest geschikt voor is. 8 Ook hier betreft het een rol die ingevuld wordt door degene die voor het onderhavige project het meest geschikt is. 9

18 Whitepaper: Prince2 en Architectuur Architectuur en projecten Escalatie naar de architectuurraad In de visie van DYA werkt een architect in een organisatie voor een opdrachtgever. De opdrachtgever is degene die een bepaald businessdoel wil realiseren. Om dat doel te realiseren is inzicht nodig in de daarvoor benodigde veranderingen. Het is de taak van de architect om die veranderingen inzichtelijk te maken en er sturing aan te geven. Dit doet hij door voor de genoemde gebieden- principes en modellen op te stellen en relevante standaarden te selecteren. Als het businessdoel daadwerkelijk in programma- of projectvorm moet worden gerealiseerd, worden projecten gestart met aan het hoofd een projectmanager. Het is de taak van de projectmanager om een oplossing te leveren binnen de kaders van de architectuur. De architect levert de principes, modellen en standaarden aan de projectmanager aan in de vorm PSA. Architect Opdrachtgever manager Figuur 4 Samenspel rollen Indien de projectmanager van mening is dat de realisatie volgens de architectuur niet past binnen tijd en budget, staat de opdrachtgever voor het besluit of hij van de architectuur afwijkt of dat er meer tijd en geld beschikbaar moet komen. Maar hij doet dit niet in isolement. Binnen de organisatie spelen meerdere businessdoelen tegelijkertijd. Om te zorgen voor consistente afstemming, om keuzes te maken en prioriteiten te stellen wordt een architectuurraad in het leven geroepen. In feite dient elk van de rollen opdrachtgever, architect en projectmanager een achterban te hebben in respectievelijk businessmanagement, architectuurmanagement en programmamanagement. Deze managementgroepen worden elk vertegenwoordigd enwoordigd in de architectuurraad, tezamen met een vertegenwoordiger van het topmanagement. Een architectuurraad is een platform voor inhoudelijke afstemming en escalatie. Architectuurraad Top management Architectuur management Business management Programma management Architect Opdrachtgever manager Figuur 5 De architectuurraad 10

19 Prince2 en Architectuur Architectuur en projecten De voornaamste taken architectuurraad zijn: o Het verstrekken van architectuuropdrachten; o Het formeel goedkeuren van architectuurproducten; o Het fungeren als escalatieplatform bij inhoudelijke conflicten. Op het moment dat een projectarchitect en/of een controlling architect constateert dat de verandering die een project aan het doorvoeren is, niet strookt met de langere termijn of niet goed aan dreigt te sluiten bij andere veranderingen (anders gezegd: niet in overeenstemming is met de architectuur), moet hij dat signaleren. Hij initieert een exception. Allereerst doet hij dat aan de ontwerper om samen met deze tot een oplossing hiervan te komen. Lukt dat niet dan zal hij escaleren naar de projectleider. Ook escaleert hij binnen de architectuurfunctie naar de Lead Architect. Deze bespreekt het issue met de projectleider en de opdrachtgever. Indien de projectmanager van mening is dat de realisatie volgens de architectuur niet past binnen tijd en budget, staat de opdrachtgever voor het besluit of hij van de architectuur afwijkt of dat er meer tijd en geld beschikbaar moet komen. Binnen de architectuurraad wordt, vanuit het bredere perspectief, besloten of de afwijking wordt toegestaan of niet en zo ja of dat dan een permanente toestemming of een tijdelijke toestemming is. Samen met de stuurgroep van het project wordt besproken wat de consequenties zijn wanneer de afwijking op de architectuur niet wordt toegestaan. Tevens wordt bekeken waar beide boards (architectuurraad en stuurgroep) elkaar kunnen vinden. Het project gaat verder met de uitkomst van het besluit dat uit deze discussie voort komt. Indien de afwijking is toegestaan kan het project zoals gepland doorgaan. Indien de uitkomst van de discussie is dat de afwijking van de architectuur niet door kan gaan, moet er naar alternatieven gezocht worden. Dit zal de uiteindelijke oplossing doen veranderen. Tevens zal het uitzoeken van het alternatief tijd en inspanning vergen, wat kan betekenen dat het project- of faseplan aangepast moet worden. Vanuit architectuuroogpunt kan een besluit van de architectuurraad en de stuurgroep ertoe leiden dat de Referentie Architectuur aangepast moet worden. Dit valt buiten de scope van deze white paper. 11

20 Whitepaper: Prince2 en Architectuur Prince2 en architectuur 3 PRINCE2 EN ARCHITECTUUR In dit hoofdstuk worden, voor zover vanuit architectuurperspectief relevant, de processen van Prince2 beschreven. De toevoeging die vanuit het werken onder architectuur voortvloeit wordt daarbij beschreven. In de eerste paragraaf wordt een totaaloverzicht gegeven. In de paragrafen daarna worden de in het overzicht genoemde punten per proces verder toegelicht. 3.1 Overzicht relatie Prince2 en architectuur Uitgangspunt van de beschrijving van de relatie tussen Prince2 en architectuur is de processtructuur van Prince2. Figuur 6 geeft deze weer. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten MP productoplevering PL Opstellen plan Figuur 6 Processtructuur Prince2 Onderstaande tabel geeft een overzicht van die punten waarbij de relatie van architectuur met Prince2 tot uitdrukking komt. Proces Relatie met architectuur OP - Opstarten project Architectuurparagraaf in het projectvoorstel; Invloed van architectuur op de projectaanpak; Plannen van de Impact Analyse en de PSA in het faseplan voor de Initiatiefase (IP). IP - Initiëren project Architectuurrequirements via de PSA; Controlling architect opnemen als reviewer; Uitvoeren van de Impact Analyse; Architectuurraad als gesprekspartner Stuurgroep; Architectuur in de projectrapportage. SP - Sturen project Architectuur als referentiekader opnemen; Afwijkingen op de architectuur behandelen; Afwijkingen op de architectuur als open issues of vervolgactie definiëren. BF - Beheersen fase Goedkeuring van de architect 12

21 Prince2 en Architectuur Prince2 en architectuur Proces Relatie met architectuur afgerond werkpakket; Afwijkingen op de architectuur als projectissues; MP - productoplevering Advies van de projectarchitect bij de uitvoering van werkpakketten; Review van producten door de controlling architect. MF - faseovergangen Architecten opnemen in de kwaliteitsplannen van de verschillende fasen; Architect raadplegen bij het actualiseren van de Business Case; Afwijkingsplan opstellen naar aanleiding van afwijkingen op de architectuur. AP - Afsluiten project Controle op het voldoen aan de architectuurcriteria; Controle op afhandeling van projectissues als gevolg van afwijkingen op de architectuur Vervolgacties als het gevolg van afwijkingen op de architectuur beleggen; PL - Opstellen plan Impact Analyse als product definiëren en plannen; PSA als product definiëren en plannen. Zoals eerder gezegd worden de in de bovenstaande tabel genoemde punten in de volgende paragrafen per proces verder besproken en toegelicht. 3.2 Opstarten project (OP) De essentie hier voor architectuur is de identificatie dat architectuur een rol speelt binnen dit project en dat de projectarchitect wordt betrokken bij het opstellen van het projectvoorstel. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Opstellen voorstel (OP4) Architectuurparagraaf aanpak definiëren (OP5) Invloed van architectuur Plannen Initiatiefase (OP6) Impact analyse PSA MP productoplevering PL Opstellen plan Figuur 7 Opstarten project 13

22 Whitepaper: Prince2 en Architectuur Prince2 en architectuur OP4 voorstel opstellen Onderdeel van het werken onder architectuur is het vaststellen van de taken, bevoegdheden en verantwoordelijkheden architect. Vanuit architectuurstandpunt hoort daar bij dat de projectarchitect tect geraadpleegd moet worden bij het opstellen van het voorstel. Onderdeel van het opstarten project is het opstellen voorstel. Een project wordt uitgevoerd om een gewenste verandering door te voeren. Vaak hebben deze veranderingen eringen een korte(re) termijn doelstelling. De essentie van het werken onder architectuur is om bij het doorvoeren van de verandering ook de lange(re) termijn in de gaten te houden. Hiertoe wordt in het voorstel een aparte architectuurparagraaf opgenomen die aangeeft op welke wijze dit project bijdraagt aan het realiseren van de langere termijn doelstellingen. Indien een schets bestaat van de toekomstige inrichting van de organisatie (zowel op business-, informatie- en/of infrastructuurarchitectuur) wordt aangegeven op welke punten dit project daarop aanhaakt. Daar waar de verandering die dit project doorvoert niet aansluit bij die toekomstige inrichting, wordt hier aangegeven waarom niet en wat de eventuele consequenties zijn. Indien het hele project bewust níét onder architectuur wordt uitgevoerd, wordt in deze paragraaf verwezen naar de Management letter OP5 aanpak definiëren De aanpak van het project wordt mede bepaald door de architectuur. Prince2 stelt dat de aanpak moet passen bij de strategie van de klant. Ook architectuur vindt zijn bestaansrecht in het realiseren van de strategie. Architectuur kan dus van invloed zijn op de aanpak die gekozen wordt. Zo kan er bijvoorbeeld voor gekozen worden om een deel van het project dat een generieke voorziening voor de hele organisatie oplevert eerder uit te voeren dan andere delen van het project OP6 Plannen Initiatiefase Tijdens de Initiatiefase wordt er, naast de PID, de Impact Analyse uitgevoerd en de PSA opgesteld. Dit moet in het plan voor die fase meegenomen worden. Het plannen zelf wordt verder beschreven in paragraaf

23 Prince2 en Architectuur Prince2 en architectuur 3.3 Initiëren project (IP) Tijdens de projectinitiatiefase wordt de fundering voor het project neergelegd in de vorm van het Initiatie Document (PID). Bij een aantal van de activiteiten die nodig zijn om dit document op te leveren speelt architectuur een rol. Deze rol wordt in deze paragraaf beschreven. De essentie is hier dat de architectuurraad als orgaan wordt geïdentificeerd en dat architectuur wordt opgenomen in de rapportage over het project. Tevens worden de Impact Analyse en de PSA opgesteld. De rol van de architecten bij de kwaliteitsbewaking wordt ook bepaald. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Kwaliteitsplan opstellen (IP1) Achitectuurrequirements (PSA) MP Controlling architect als reviewer Business case & risico s aanscherpen (IP3) productoplevering Uitvoeren Impact Analyse beheersing opzetten (IP4) Architectuurraad Architectuur in rapportage PL Opstellen plan IP1 Kwaliteitsplan opstellen 15 Figuur 8 Initiëren project Met het werken onder architectuur wordt het voldoen aan de richtlijnen en standaarden die door de architectuur gesteld worden, een onderdeel van de kwaliteit van de opgeleverde producten. De architectuur stelt additionele requirements die door het project moeten worden gerealiseerd. Deze requirements maken zodoende onderdeel uit van de verwachte kwaliteit. Prince2 stelt dat in het kwaliteitsplan aandacht besteed moet worden aan de kwaliteitsnormen die door de klant en de leverancier worden gehanteerd. Hier komt nu een derde bron bij: de architectuur. Deze additionele architectuurrequirements worden duidelijk gemaakt via de start-architectuur (PSA). Deze architectuurrequirements moeten ervoor zorgen dat de oplossing die het project oplevert past in het grotere geheel en in lijn is met de langere termijn doelstellingen van de organisatie. Hiertoe wordt het relevante deel van de principes, richtlijnen en modellen vanuit de Referentie Architectuur geconcretiseerd voor het onderhavige project. Deze concretisering levert dan de architectuurrequirements op. Doel van deze concretisering is dat de architectuurrequirements door het project op dezelfde manier behandelt kunnen worden als de requirements vanuit de business, de gebruiker of het systeem. De projectarchitect stelt deze PSA op. Hiertoe maakt hij afspraken met de projectleider over inspanning, doorlooptijd en oplevermoment en over de kwaliteitscriteria. De project- en de controlling architect zijn twee van de kwaliteitsborgingfuncties voor dit project. Dit zal in het kwaliteitsplan aangegeven moeten worden. Tevens wordt hierbij aangegeven of en in hoeverre deze twee rollen door dezelfde functionaris kunnen worden vervuld. De communicatielijnen zullen dus ook met deze architecten

24 Whitepaper: Prince2 en Architectuur Prince2 en architectuur opgezet moeten worden. Ook moet de controlling architect betrokken worden als één van de reviewers bij een kwaliteitsreview IP3 Business case & Risico s aanscherpen Eén van de hoofdtaken van architectuur is om inzicht te verschaffen in de samenhang en structuur van de inrichting organisatie. Bij een goede architectuur is dat inzicht aanwezig. Dat inzicht is bij uitstek een geschikt uitgangspunt om de impact te bepalen van de verandering die het project door wilt voeren op de bestaande situatie. Impact Analyses worden doorgaans uitgevoerd door business analisten of vergelijkbare functionarissen. De projectarchitect ondersteunt hem daarbij, vanwege het hierboven genoemde inzicht vanuit architectuur. Daar waar nodig kunnen zij experts op verschillende relevante terreinen inschakelen. De Impact Analyse wordt uitgevoerd ten behoeve van de Business Case om inzicht te krijgen in de omvang en complexiteit van de voorgestane verandering en de risico s die daarbij gelopen worden. Vanuit architectuur gezien is het risico samen te vatten als dat de uiteindelijke oplossing niet in het grotere geheel past of niet toekomstbestendig is. Voor het opstellen van deze Impact Analyse worden afspraken gemaakt tussen de projectleider en de business analist (met de projectarchitect) over inspanning, doorlooptijd en oplevermoment van de Impact Analyse en over de kwaliteitscriteria. Het inzicht dat uit de Impact Analyse komt kan dan door de projectleider gebruikt worden om een inschatting te maken van inspanning, doorlooptijd en daarmee kosten. Deze inschatting vindt zijn neerslag in het Initiatie Document (PID) IP4 beheersing opzetten Bij dit proces worden de controlepunten en de rapportages voor het project vastgesteld. In de paragraaf Architectuur en projecten (paragraaf 2.2) is gesteld dat met het werken onder architectuur de Architectuurraad een rol te spelen heeft in het project. Deze rol moet hier geïdentificeerd worden, samen met het samenspel tussen deze Architectuurraad en de Stuurgroep. Zowel de rol als het samenspel zijn natuurlijk al buiten dit project vastgesteld. Dit betekent ook dat het voldoen aan de architectuur (als onderdeel van de kwaliteit) onderdeel is van de standaardrapportage van het project. 3.4 Sturen (SP) De essentie voor architectuur binnen dit proces is dat de architectuur als referentiekader wordt herkend en dat afwijkingen op de architectuur afdoende worden behandeld. 16

25 Prince2 en Architectuur Prince2 en architectuur SP Sturen OP Opstarten initiatie autoriseren (SP1) IP Architectuur als BF referentiekader MF AP opnemen Initiëren Beheersen Afsluiten Ad hoc sturing geven (SP4) Faseovergangen Afwijkingen op de architectuur Fase afsluiting bevestigen (SP5) Afwijkingen als open issue en/of vervolgacties MP productoplevering PL Opstellen plan Figuur 9 Sturen project SP1 initiatie autoriseren Eén van de vragen voor het autoriseren van de projectinitiatie is of er een geschikt referentiekader is. Vanuit de architectuur wordt deze referentie geboden in een Referentie Architectuur (RA). Dit ondersteunt de vaststelling of de projectdoelstellingen binnen de bedrijfs- of programmadoelstellingen passen. Deze Referentie Architectuur moet dus in de beoordeling meegenomen worden SP4 - Ad hoc sturing geven Onderdeel van het Ad hoc sturing geven is het oordelen over Afwijkingsrapporten en beslissen over projectvraagstukken die onder hun aandacht zijn gebracht. Eén van deze afwijkingen dan wel projectvraagstukken zijn de afwijkingen op de architectuur. Deze architectuurafwijkingen worden door de projectarchitect gesignaleerd en via de projectleider naar de Stuurgroep geëscaleerd. Ondertussen zal de projectarchitect de afwijking via de Lead Architect naar de Architectuurraad escaleren. De Architectuurraad neemt contact op met de Stuurgroep om tot een besluit te komen. Het project gaat verder met het besluit dat door de Architectuurraad wordt genomen SP5 - afsluiting bevestigen Bij de projectafsluiting wordt gecontroleerd of er nog openstaande projectissues zijn en worden aanbevelingen voor vervolgacties goedgekeurd. In de loop van het project kunnen afwijkingen op de architectuur zijn voorgekomen, waarvan besloten is dat deze (tijdelijk) toegestaan zijn. In de discussie tussen de Stuurgroep en de Architectuurraad dient ook besloten te zijn wie verantwoordelijk is voor het opruimen of oplossen van de afwijking. Er is in principe de keuze tussen het project (cq. de Stuurgroep) of de architectuurfunctie (cq. de Architectuurraad). Indien besloten is dat het project verantwoordelijk wordt gesteld voor het oplossen van de afwijking op de architectuur, leidt dat tot een openstaand projectissue, danwel vervolgacties die goedgekeurd moeten worden. 17

26 Whitepaper: Prince2 en Architectuur Prince2 en architectuur 3.5 Beheersen Fase (BF) De essentie voor architectuur bij dit proces is dat de afwijkingen op de architectuur als projectissues geïdentificeerd, besproken en eventueel geëscaleerd worden. Tevens dienen de opgeleverde producten de goedkeuring van de controlling architect te hebben. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Afgerond werkpakket ontvangen (BF9) Goedkeuring architect MP productoplevering issues verzamelen (BF3) issues beoordelen (BF4) issues escaleren (BF8) Afwijkingen op de architectuur PL Opstellen plan BF3 - issues verzamelen Figuur 10 Beheersen Fase Een geconstateerde afwijking op de architectuur is een projectissue dat in het issuelogboek moet worden vastgelegd. Er kan gekozen worden om de afwijking als zodanig te registreren of als een negatief resultaat review. Afwijkingen worden namelijk doorgaans geconstateerd in het kader van reviews op producten. Uiteraard hoeft men niet te wachten tot de review voordat het issue aan de projectleider wordt gemeld als het al eerder is geconstateerd. Als nadat de afwijking is geconstateerd de ontwerper en de projectarchitect samen een oplossing hebben gevonden die wel binnen de kaders van de architectuur blijft, is de afwijking weggenomen en hoeft er uiteraard geen issue te worden vastgelegd BF4 - issues beoordelen Het hierboven geregistreerde projectissue van de afwijking van de architectuur moet conform de andere projectissues afgehandeld worden. Dus ook voor dit issue wordt de impact op de inspanning bepaald, de invloed op de Business Case bekeken, eventueel het risicologboek bijgewerkt, aanbevelingen gedaan voor vervolgacties, enzovoorts. Dit gebeurt hier wel in het kader van de discussie die gevoerd wordt of is tussen de Stuurgroep en de Architectuurraad BF8 - issues escaleren Vanuit hier wordt, in het kader van de architectuur, eventuele afwijkingen op die architectuur als projectissue geëscaleerd naar de Stuurgroep. Hiertoe wordt een 18

27 Prince2 en Architectuur Prince2 en architectuur Afwijkingsrapport opgesteld. De Stuurgroep zal naar aanleiding hiervan de discussie met de Architectuurraad aangaan BF9 - Afgerond Werkpakket ontvangen Bij het ontvangen werkpakket wordt gecontroleerd dat deze conform de afspraken is uitgevoerd. Ook wordt de productbeschrijving met de bijbehorende acceptatiecriteria en bijbehorende kwaliteitsbeoordeling geverifieerd. Het voldoen aan de architectuurrequirements is hier een onderdeel van. De goedkeuring van de producten door de controlling architect wordt eventueel gevisualiseerd door een boouwvergunning of een architectuurcertificaat. 3.6 productoplevering (MP) De essentie voor architectuur bij dit proces is dat de rol van de projectarchitect als adviseur en die van de controlling architect bij de kwaliteitsreviews is vastgelegd. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Werkpakket aannemen (MP1) Werkpakket uitvoeren (MP2) Advies op basis van PSA Kwaliteitsreviews MP productoplevering PL Opstellen plan MP1 - Werkpakket aannemen Figuur 11 productoplevering Werkpakketten gaan in het kader van deze white paper over projectproducten die op architectuuraspecten gecontroleerd moeten worden. Bij deze werkpakketten moet vastgesteld worden wie bij de kwaliteitsreviews betrokken moeten worden. De controlling architect is doorgaans één van de onafhankelijke personen die bij de kwaliteitsreviews betrokken moeten worden. Dit wordt hier vastgesteld. Hierin is meegenomen of de rol van controlling architect door dezelfde persoon wordt uitgevoerd als de projectarchitect of niet. 19

28 Whitepaper: Prince2 en Architectuur Prince2 en architectuur MP2 - Werkpakket uitvoeren Tijdens de uitvoering werkpakket geeft de projectarchitect advies ten aanzien van de inhoud van het op te leveren product. Hij baseert zich daarbij op de architectuurrequirements zoals die in de PSA zijn vastgelegd. De controlling architect is betrokken als reviewer om te controleren of op basis van de inhoud van het betreffende product er nog van uitgegaan kan worden dat het resultaat zal voldoen aan de architectuur. Er moet op toegezien worden dat de controlling architect inderdaad betrokken wordt bij de uitvoering van de kwaliteitsreview. 3.7 faseovergangen (MF) De essentie bij dit proces voor architectuur is dat architecten betrokken zijn bij kwaliteitsreviews, dat de impact analyse gebruikt wordt bij het herzien van de business case en dat consequenties van het afwijken van de architectuur daar waar nodig worden meegenomen in de plannen die gemaakt worden voor de volgende fase. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten MP productoplevering Faseplan opstellen (MF1) Kwaliteitsreviews Business case actualiseren (MF2) Raadplegen Afwijkingsplan opstellen Afwijkingen op de architectuur PL Opstellen plan MF1 Faseplan opstellen Figuur 12 faseovergangen Onderdeel van het faseplan zijn de kwaliteitsreviews. Deze worden aan het plan toegevoegd en voor de kwaliteitsreviews wordt een voorzitter geïdentificeerd. Specifiek voor architectuur kunnen kwaliteitsreviews worden uitgevoerd. De projectarchitect is daarvan de voorzitter. Dit moet in het faseplan opgenomen worden MF3 Business case actualiseren Aan het eind van elke fase gaat de projectleider na in hoeverre de Business Case nog actueel is. Dit doet hij in overleg met de Stuurgroep, die immers verantwoordelijk blijft voor het realiseren van de Business Case. Bij het actualiseren van de business case wordt de architect geraadpleegd. Deze heeft immers de business analist ondersteunt bij het uitvoeren van de Impact Analyse. Vanuit zijn begeleiding van het 20

29 Prince2 en Architectuur Prince2 en architectuur project heeft hij inzicht in de wijziging in de impact zoals die oorspronkelijk is vastgesteld. Wanneer voor het actualiseren van de Business Case een nieuwe Impact Analyse wordt uitgevoerd, kan de projectarchitect deze wederom ondersteunen MF6 Afwijkingsplan opstellen Een afwijking van de architectuur, die eerder als issue is geëscaleerd, kan leiden tot een afwijking van het oorspronkelijke plan. Dit kan dus een reden zijn om een afwijkingsplan op te stellen. 3.8 Afsluiten project (AP) De essentie voor architectuur voor dit proces is dat het project mede beoordeeld wordt op het voldoen aan de architectuur. Tevens moeten eventuele vervolgacties die het gevolg zijn van afwijkingen op de architectuur, geïdentificeerd en belegd worden. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten MP productoplevering afbouwen (AP1) Architectuurcriteria Afwijkingen als projectissues Vervolgacties identificeren (AP2) Afwijkingen op de architectuur PL Opstellen plan AP1 afbouwen Figuur 13 Afsluiten project Onderdeel van deze activiteit is de controle dat het eindresultaat aan de acceptatiecriteria voldoet. Vanuit architectuur zijn ook acceptatiecriteria opgesteld die in deze evaluatie mee moeten worden genomen. Afwijkingen op de architectuur zijn eerder als projectissues geëscaleerd en besproken tussen de Stuurgroep en de Architectuurraad. Controle op het afhandelen van de projectissues betreft dus ook deze afwijkingen. 21

30 Whitepaper: Prince2 en Architectuur Prince2 en architectuur AP2 Vervolgacties identificeren Afwijkingen op de architectuur kunnen leiden tot vervolgacties. In deze activiteit moet dus gecontroleerd worden dat deze afwijkingen afdoende zijn geïdentificeerd en belegd. 3.9 Opstellen plan (PL) De essentie voor architectuur bij dit proces is dat de inspanningen voor het project vanuit de architectuur mee ingepland worden. Dit betreft zowel het opstellen van de Impact Analyse en de PSA als de bijdrage van architecten aan andere documenten. SP Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Producten definiëren en analyseren (PL2) Activiteiten en afhankelijkheden identificeren (PL3) Schatting maken (PL4) Tijdschema opstellen (PL5) PSA Impact Analyse MP productoplevering PL Opstellen plan Figuur 14 Opstellen plan PL2 - Producten definiëren en analyseren Bij dit proces worden de op te leveren producten geïdentificeerd. Van elk product wordt een productbeschrijving opgesteld, waaronder het doel, de samenstelling, de specificaties en de kwaliteitscriteria. Eén van de standaardproducten, die altijd opgeleverd moet worden indien onder architectuur wordt gewerkt, is de PSA. De Impact Analyse is een ander product waarbij architectuur een grote rol speelt, dat gedefinieerd moet zijn en dus beschreven. Daarnaast kunnen nog andere architectuurproducten gewenst zijn, zoals een aanpassing van de Referentie Architectuur of het verder uitwerken van architectuurmodellen. Deze worden echter doorgaans niet in het kader project opgesteld en vallen dus buiten de verantwoordelijkheid van het project. Wel kan het project een trigger zijn voor het opstellen van deze producten. Dit kan eventueel van invloed zijn op de doorlooptijd van de PSA en de Impact Analyse. Dit wordt uitgelegd in paragraaf

31 Prince2 en Architectuur Prince2 en architectuur PL3 - Activiteiten en afhankelijkheden identificeren Dit proces, dat binnen Prince2 voor elk product geldt, geldt dan ook voor de producten PSA en Impact Analyse. Onderdeel van deze activiteiten is dan ook de beoordeling van de kwaliteit van deze producten PL4 - Schatting maken Het maken van schattingen voor activiteiten en producten geldt ook voor de PSA en de Impact Analyse PL5 - Tijdschema opstellen Het opstellen van de PSA en de Impact Analyse moet in de tijdschema's meegenomen worden. Ook hiervoor moet tijd en middelen vrijgemaakt en ingepland worden. Bij het opstellen PSA wordt gebruik gemaakt van de Referentie Architectuur. In deze Referentie Architectuur staan de principes, richtlijnen en standaarden die bij toekomstige ontwikkelingen (lees: het uitvoeren ook dit- project) gehanteerd moeten worden. Daarnaast geeft een Referentie Architectuur een schets van de gewenste toekomstige situatie, zodat daar bewust naartoe gewerkt kan worden. Als derde onderdeel kan de Referentie Architectuur een beeld van de huidige situatie bevatten. In de praktijk blijkt dit niet altijd het geval. Wanneer delen van de Referentie Architectuur niet (voldoende) zijn ingevuld, om op basis daar PSA op te kunnen stellen, dan moet dat bij deze gebeuren. Het onderhavige project is dan de trigger om die invulling te gaan maken. Hier moet in het tijdschema rekening mee worden gehouden. De inspanning voor het maken PSA zal dan niet anders zijn, maar de doorlooptijd wel. Het opstellen van de PSA moet namelijk wachten totdat het betreffende deel van de Referentie Architectuur (voldoende) is ingevuld. Deze verlening van de doorlooptijd geldt ook voor de Impact Analyse. Hoe beter de huidige situatie in kaart is gebracht, des te sneller een Impact Analyse kan worden opgesteld. Naarmate deze huidige situatie minder in kaart gebracht is, zal ook hier eerst een extra inspanning plaats moeten vinden, voordat de Impact Analyse uitgevoerd kan worden. Het is afhankelijk van de afspraken binnen een organisatie of de inspanning van het in kaart brengen van de huidige situatie dan wel of niet op het budget van het project drukt. In grote lijn zijn de volgende twee redenaties mogelijk: 1. Het project moet uitgevoerd worden. Daarvoor is een impact analyse nodig. Voor een impact analyse is een beeld van de huidige situatie nodig. De inspanningen hiervoor drukken dus op het budget van het project; 2. Een beeld van de huidige situatie heeft de organisatie nodig, ook los van dit project. De inspanningen die daarvoor nodig zijn moeten dan ook los van dit project uitgevoerd en bekostigd worden. 23

32 Whitepaper: Prince2 en Architectuur Thema s met architectuur binnen projecten 4 THEMA S MET ARCHITECTUUR BINNEN PROJECTEN In dit hoofdstuk wordt de relatie tussen Prince2 en architectuur nogmaals beschreven, maar nu vanuit het perspectief aantal thema's. Bij het lezen van het vorige hoofdstuk is mogelijk opgevallen dat dezelfde thema's bij meerdere processen van Prince2 terugkomen. In dit hoofdstuk worden al deze verschillende processen per thema bij elkaar gezet en beschreven. 4.1 Inrichting van het project Om architectuur goed aan te laten sluiten op het project moet bij de inrichting van dat project met een aantal architectuuraspecten rekening worden gehouden. Figuur 15 toont deze aspecten. SP beheersing opzetten (IP4) Architectuurraad Architectuur in rapportage Sturen OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Opstellen voorstel (OP4) Architectuurparagraaf aanpak definiëren (OP5) Invloed van architectuur initiatie autoriseren (SP1) Architectuur als referentiekader MP opnemen productoplevering PL Opstellen plan Figuur 15 Inrichting Het voorstel, dat wordt opgesteld tijdens de opstartfase project (OP4) bevat een architectuurparagraaf. Deze architectuurparagraaf geeft aan op welke wijze dit project bijdraagt aan het realiseren van de langere termijn doelstellingen. Indien in de Referentie Architectuur een schets bestaat van de toekomstige inrichting van de organisatie (zowel op business-, informatie- en/of infrastructuurarchitectuur) wordt aangegeven op welke punten dit project daarop aanhaakt. Daar waar de verandering die dit project doorvoert niet aansluit bij die toekomstige inrichting, wordt hier aangegeven waarom niet en wat de eventuele consequenties zijn. Architectuur kan van invloed zijn op de aanpak van het project. Als dat het geval is, moet dat in de beschrijving van die aanpak (OP5) terugkomen. De twee architectuuraspecten die bij de opzet van de beheersing van het project (IP4) terugkomen zijn de rol van de Architectuurraad (zie paragraaf 2.2.3) en het opnemen van de architectuur als één van de aspecten in de rapportage aan de Stuurgroep. Deze twee aspecten moeten bij het opzetten van de projectbeheersing als standaardonderdeel meegenomen enomen worden. Het instellen van de Architectuurraad en het opnemen van architectuur in de standaardrapportage hoeft natuurlijk slechts eenmalig te worden ingericht. Elk project hanteert dan deze standaardinrichting. 24

33 Prince2 en Architectuur Thema s met architectuur binnen projecten Onderdeel van het autoriseren van de projectinitiatie (SP1) is het aangeven welke referentiekaders bij het project gehanteerd zullen worden. De Referentie Architectuur is standaard één van deze kaders. 4.2 Impact Analyse Impact Analyses ten behoeve project worden doorgaans uitgevoerd door business analisten of soortgelijke functionarissen. Architecten zijn bij uitstek geschikt om daarbij te assisteren. Dit komt doordat architecten, als het goed is, inzicht hebben in de samenhang en structuur van de inrichting organisatie in al zijn facetten van business, informatie en infrastructuur. Dit beeld is mogelijk vastgelegd in de Referentie Architectuur. Het uitvoeren van de Impact Analyse moet in de projectplannen meegenomen worden. Figuur 16 laat zien waar de Impact Analyse in de processen van Prince2 terugkomt. SP Sturen Business case & risico s aanscherpen (IP3) Uitvoeren Impact Analyse OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Producten definiëren en analyseren (PL2) Activiteiten en afhankelijkheden identificeren (PL3) Schatting maken (PL4) Tijdschema opstellen (PL5) MP productoplevering Business case actualiseren (MF2) Raadplegen PL Opstellen plan Figuur 16 Impact Analyse De Impact Analyse wordt uitgevoerd ten behoeve van de Business Case en het aanscherpen van de risico's (IP3). Dit bepaalt het moment in het project waarop de Impact Analyse gedaan wordt: de Impact Analyse is één van de producten die de fase IP op zal leveren. Dit betekent dat de Impact Analyse opgenomen moet zijn in het Productstroomschema. Het moet geïdentificeerd en beschreven zijn en er moet zijn aangegeven waar in de volgorde van producten de Impact Analyse zijn plek heeft (PL2). Voor het opstellen van de Impact Analyse moeten de benodigde activiteiten en hun onderlinge afhankelijkheden geïdentificeerd zijn (PL3). Vervolgens moet voor deze activiteiten de benodigde inspanning geschat worden (PL4) en moeten deze activiteiten in het tijdschema worden opgenomen (PL5). Indien voor het opstellen van de Impact Analyse eerst aanvullende activiteiten moeten worden uitgevoerd (bijvoorbeeld het in kaart brengen van de huidige situatie), zal dat in het tijdschema (PL5) tot uitdrukking komen. Indien deze activiteiten op kosten van het project uitgevoerd moeten worden, zal de inspanning voor het project (PL4) groter zijn. 25

34 Whitepaper: Prince2 en Architectuur Thema s met architectuur binnen projecten Voor het uitvoeren van de Impact Analyse maakt de business analist en de projectarchitect afspraken met de projectleider over inspanning, doorlooptijd en oplevermoment en over de kwaliteitscriteria. Aan het eind van elke fase gaat de projectleider na in hoeverre de Business Case nog actueel is. Dit doet hij in overleg met de Stuurgroep, die immers verantwoordelijk blijft voor het realiseren van de business case. De projectleider kan daarbij gebruik maken van de impact analyse die eerder is opgesteld. Tevens raadpleegt hij de architect. Deze heeft immers de business analist ondersteunt bij het uitvoeren van de Impact Analyse. Vanuit zijn begeleiding van het project heeft hij inzicht in de wijziging in de impact zoals die oorspronkelijk is vastgesteld. Dit kan de projectleider dan meenemen in zijn beoordeling. Wanneer voor het actualiseren van de Business Case een nieuwe Impact Analyse wordt uitgevoerd, kan de projectarchitect de business analist wederom ondersteunen. 4.3 Kwaliteit Met het werken onder architectuur wordt het voldoen aan de richtlijnen en standaarden die door de architectuur gesteld worden, een onderdeel van de kwaliteit van de opgeleverde producten. Figuur 17 laat zien waar het opstellen en toetsen van architectuur als kwaliteitsnorm in de Prince2 processen terugkomt. SP Sturen Faseplan opstellen (MF1) Kwaliteitsreviews OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Kwaliteitsplan opstellen (IP1) Achitectuurrequirements Controlling architect als reviewer Kwaliteitsreviews op producten MP productoplevering afbouwen (AP1) Architectuurcriteria Afgerond werkpakket ontvangen (BF9) Goedkeuring architect PL Opstellen plan Figuur 17 Kwaliteit De kwaliteitsnormen bestaan bij het werken onder architectuur niet alleen meer uit de eisen die de klant en de leverancier stellen. De eisen vanuit de architectuur worden hieraan toegevoegd. Deze worden vastgelegd in de PSA (zie paragraaf 4.4). Het toezien op de kwaliteitseisen vanuit de architectuur is de taak van de controlling architect. Deze moet dus als reviewer aangemerkt worden. Beide aspecten komen terug in het kwaliteitsplan (IP1). Bij het managen fase wordt een fase plan opgesteld (MF1) voor de volgende fase. Onderdeel van dat plan is de identificatie van de kwaliteitreviews die uitgevoerd moeten worden. Ook wordt aangegeven wie van deze reviews de voorzitter is en wie er verder bij betrokken zijn. De reviews ten aanzien van de kwaliteitseisen vanuit de architectuur moeten hierin meegenomen worden. De controlling architect is deelnemer 26

35 Prince2 en Architectuur Thema s met architectuur binnen projecten aan deze reviews en de projectarchitect kan zelfs voor sommige van deze reviews de voorzitter zijn. 9 Bij het van de productoplevering (MP) worden de reviews daadwerkelijk uitgevoerd. Wanneer de architect de kwaliteit van het onderhavige product goedkeurt geeft hij een bouwvergunning en/of architectuurcertificaat af voor dat product. Met deze bouwvergunning of architectuurcertificaat geeft de controlling architect aan dat het onderhavige product is gereviewd en vanuit het architectuurperspectief is goedgekeurd. Bij het in ontvangst nemen van het werkpakket (BF9) controleert de projectleider op het bestaan van die vergunning of dat certificaat. Wanneer de architect constateert dat niet aan de eisen van de architectuur is voldaan kan hij of de afwijking weg (laten) halen of zal hij escaleren. Dit laatste is al beschreven in paragraaf De plaats van afwijkingen binnen Prince2 is beschreven in paragraaf 4.5. Wanneer het project is afgerond moet gecontroleerd worden dat aan alle kwaliteitseisen is voldaan (AP1). De eisen vanuit de architectuur worden in deze controle meegenomen. Los van het gebruik van de PSA ten behoeve van de kwaliteit, zoals hierboven beschreven, moet ook de PSA zelf een voldoende kwaliteit hebben. De PSA moet dus zelf ook beoordeeld worden op de kwaliteit ervan. Dit geldt ook voor de Impact Analyse, die aan bepaalde kwaliteitscriteria moet voldoen. 4.4 PSA De PSA ( Start Architectuur) is een document, waarin de architectuur is beschreven zoals deze geldt bij de start project. Het document is bedoeld als verbinding tussen de architectuur aan de ene kant en een project aan de andere kant. De PSA is een stuurinstrument dat er voor zorgt dat architectuur niet beperkt blijft tot de ivoren toren van de architect, maar dat de architectuur concreet maakt om de veranderingen in een organisatie te faciliteren. De uitwerkingen van deze veranderingen worden hoofdzakelijk binnen projecten uitgewerkt tot businessoplossingen. De PSA is een vertaling van de algemene principes en beleidslijnen naar een projectspecifiek kader. Relevante onderdelen uit de algemene (Referentie)architectuur worden toegesneden op de scope en de specifieke problematiek van het project. Hierdoor geeft de PSA een heel concreet en doelgericht architectuurkader aan, waarbinnen het project moet worden uitgevoerd. Dit kader bestaat uit de concrete standaarden, normen en richtlijnen en uit de modellen die het project dient te hanteren. Ook projectoverstijgende ontwerpkeuzes worden in de PSA vastgelegd. De PSA geeft dus de context en de richting van de oplossing project weer, maar niet de oplossing zelf. De PSA gaat niet over de 'solution architecture'. De PSA wordt uitgebreid beschreven in [5]. Figuur 18 laat zien waar de PSA in de processen van Prince2 terugkomt. 9 In paragraaf is aangegeven dat deze twee rollen door dezelfde persoon ingevuld kunnen zijn. Om de rol duidelijk te houden heb ik hier toch alle twee de rollen vermeld. 27

36 Whitepaper: Prince2 en Architectuur Thema s met architectuur binnen projecten SP Sturen Kwaliteitsplan opstellen (IP1) Architectuurrequirements (PSA) OP Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten Producten definiëren en analyseren (PL2) Activiteiten en afhankelijkheden identificeren (PL3) Schatting maken (PL4) Tijdschema opstellen (PL5) MP productoplevering issues escaleren (BF8) PL Opstellen plan Figuur 18 PSA De PSA wordt opgesteld op basis van het projectvoorstel. De PSA bestaat uit de concrete standaarden, normen en richtlijnen en uit de modellen die het project dient te hanteren. Daarmee zijn de onderdelen van dit architectuurkader requirements geworden die door het project beantwoord moeten worden (IP1). Dit zagen we ook al terugkomen in paragraaf Dit bepaalt het moment in het project waarop de PSA opgesteld moet worden: de PSA is één van de producten die de fase IP op zal leveren. Dit betekent dat de PSA opgenomen moet zijn in het Productstroomschema. Het moet geïdentificeerd en beschreven zijn en er moet zijn aangegeven waar in de volgorde van producten de PSA zijn plek heeft (PL2). Voor het opstellen van de PSA moeten de benodigde activiteiten en hun onderlinge afhankelijkheden geïdentificeerd zijn (PL3). Vervolgens moet voor deze activiteiten de benodigde inspanning geschat worden (PL4) en moeten deze activiteiten in het tijdschema worden opgenomen (PL5). Indien voor het opstellen van de PSA eerst aanvullende activiteiten moeten worden uitgevoerd (bijvoorbeeld het verder invullen van de Referentie Architectuur), zal dat in het tijdschema (PL5) tot uitdrukking komen. Indien deze activiteiten op kosten van het project uitgevoerd moeten worden, zal de inspanning voor het project (PL4) groter zijn. Voor het opleveren van de PSA maken de projectleider en de projectarchitect onderling afspraken over de inhoud, het moment en de kwaliteit. Na oplevering van de PSA neemt de projectleider de architectuurrequirements mee in het door hem op te stellen PID. In deze zin hebben het PID en de PSA hetzelfde begingpunt het projectvoorstel maar wordt de PSA iets eerder opgeleverd dan de PID. Wanneer tijdens de uitvoering van de verschillende werkpakketten afwijkingen op de architectuur geconstateerd zijn, worden deze eventueel geëscaleerd naar de Stuurgroep en de Architectuurraad (BF8). Dit wordt verder beschreven in paragraaf Afwijkingen die na de discussie tussen deze twee organen (tijdelijk) worden toegestaan, worden vastgelegd in de PSA. 28

37 Prince2 en Architectuur Thema s met architectuur binnen projecten 4.5 Afwijkingen op de architectuur Binnen Prince2 bestaat het change proces voor het afhandelen van wijzigingen en dat issues voor zijn rekening neemt. Met het werken onder architectuur verandert er niets aan dit proces. Wel kan de bron afwijking gelegen zijn in het niet voldoen aan de architectuur. Afwijkingen op de architectuur komen twee maal terug in de Prince2 procesgang. Ten eerste ten tijde van de constatering van de afwijking tijdens het ontwikkelproces. Ten tweede zijn de afwijkingen op de architectuur onderwerp van gesprek aan het einde van het project, bij de afronding ervan. SP Sturen Ad hoc sturing geven (SP4) afsluiting bevestigen (SP5) Afwijkingen als open issue en/of OP vervolgacties Opstarten IP BF MF AP Initiëren Beheersen Fase Faseovergangen Afsluiten issues verzamelen (BF3) issues beoordelen (BF4) issues escaleren (BF8) Kwaliteitsreviews op producten MP productoplevering Afwijkingsplan opstellen afbouwen (AP1) Afwijkingen als projectissues Vervolgacties identificeren (AP2) PL Opstellen plan Figuur 19 Afwijkingen op de architectuur Afwijkingen op de architectuur worden geïdentificeerd tijdens de review van de verschillende producten bij de oplevering daarvan (MP). De controlling architect is één van de reviewers. Op het moment dat hij de afwijking constateert gaat hij in overleg met de opsteller van dat product om te zien of een aanpassing mogelijk is. Indien de aanpassing niet kan (en dus de afwijking blijft bestaan) escaleert de architect naar de projectleider. Deze behandelt de afwijking als een projectissue (BF). De projectleider verzamelt deze (BF3), beoordeelt het (BF4) en escaleert door naar de Stuurgroep (BF4). Ondertussen heeft de controlling architect ook geëscaleerd naar de architectuurfunctie (via de Lead Architect naar de Architectuurraad). De Stuurgroep zal vanuit zijn sturende rol (SP4) met de architectuurraad in gesprek gaan over de afwijkingen en hoe hiermee om te gaan. De uitkomst van deze discussie wordt teruggerapporteerd aan de projectleider (afwijking mag wel, niet, tijdelijk of wat de uitkomst ook mag zijn) die in het vervolg van het project hier rekening mee houdt. Indien de afwijking (tijdelijk) wordt toegestaan wordt deze opgenomen in de PSA (zie paragraaf 4.4). Eén van de gevolgen van de afwijking op de architectuur kan zijn dat het leidt tot een afwijking van het oorspronkelijke plan. Zeker indien de afwijking niet wordt toegestaan en dus reparatiewerkzaamheden verricht moeten worden. Dit kan dus een reden zijn dat de projectleider een afwijkingsplan op moet stellen. De afwijkingen op de architectuur komen ook terug bij de afronding van het project. Onderdeel van deze activiteit is de controle dat het eindresultaat aan de acceptatiecriteria voldoet. Afwijkingen op de architectuur zijn uitdrukking dat aan bepaalde criteria niet is voldaan. Bij de discussie tussen de Stuurgroep en de 29

38 Whitepaper: Prince2 en Architectuur Thema s met architectuur binnen projecten Architectuurraad over deze afwijkingen is al besproken hoe hier in de toekomst mee omgegaan wordt. Bij de afronding van het project moet de projectleider vaststellen welke vervolgacties volgen uit deze afwijkingen. In deze activiteit moet dus gecontroleerd worden dat deze afwijkingen afdoende zijn geïdentificeerd en belegd. De daadwerkelijke afhandeling van de afwijkingen, zoals latere reparatiewerkzaamheden of aanpassing van de Referentie Architectuur, valt buiten de scope van deze white paper. Dat wordt dus hier niet verder beschreven. Het is de taak van de projectleider om deze vervolgactiviteiten goed te beleggen. Hierbij heeft hij ondersteuning van de Stuurgroep en de Architectuurraad. 30