WHITE PAPER PRINCE2 EN ARCHITECTUUR

WHITE PAPER

PRINCE2 EN ARCHITECTUUR JOOST LUIJPERS

WHITE PAPER PRINCE2 EN ARCHITECTUUR ARCHITECT

Joost Luijpers

Versie: 1.1 juli 2009

Copyright Sogeti Nederland B.V. © 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 Sogeti Nederland B.V.

Sogeti Nederland B.V. juli 2009

1.1

I

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 Projectmanager Informatie architect Informatie architect Projectmanager Projectmanager Informatie architect Projectmanager Informatie architect Informatie architect

1.1

1

Whitepaper: Prince2 ce2 en Architectuur

INHOUDSOPGAVE REVIEWERS ................................................................ ................................................................................... 1 INHOUDSOPGAVE ................................................................ ............................................................................ 2 1

2

INLEIDING ................................................................ .............................................................................. 1 1.1

Doel van het document ................................................................ ...........................................1

1.2

Doelgroep ............................................................................................ ................................ ............................1

1.3

Opzet van het document ................................................................ .........................................2

1.4

Verwachte voorkennis ................................................................ .............................................2

ARCHITECTUUR EN PROJECTEN PROJ ..................................................... ..................... 3 2.1

2.2

3

DYA in een notendop ................................................................ ..............................................3 2.1.1

Het DYA--model ................................................................ ............................................3

2.1.2

Het architectuurraamwerk ............................................................. .............................6

Architectuur en projecten ................................................................ ........................................8 2.2.1

Projectarchitect ................................................................ ..........................................9

2.2.2

Controlling architect ................................................................ ....................................9

2.2.3

Escalatie naar de architectuurraad ................................................. ................................ 10

PRINCE2 EN ARCHITECTUUR ARCHITECT ........................................................ ........................ 12 3.1

Overzicht relatie Prince2 en architectuur ................................................... ................................ 12

3.2

Opstarten van een project (OP) ............................................................... ............................... 13

3.3

3.4

3.5

3.2.1

OP4 – Projectvoorstel opstellen ..................................................... ................................ 14

3.2.2

OP5 – Projectaanpak definiëren ..................................................... ................................ 14

3.2.3

OP6 – Plannen Initiatiefase ........................................................... ........................... 14

Initiëren van een project (IP) ................................................................ .................................. 15 3.3.1

IP1 – Kwaliteitsplan opstellen ........................................................ ........................ 15

3.3.2

IP3 – Business case & Risico’s aanscherpen ........................................ ................................ 16

3.3.3

IP4 – Projectbeheersing opzetten ................................................... ................................ 16

Sturen van een Project (SP) ................................................................ .................................... 16 3.4.1

SP1 – Projectinitiatie autoriseren ................................................... ................................ 17

3.4.2

SP4 - Ad hoc sturing geven ............................................................ ............................ 17

3.4.3

SP5 - Projectafsluiting bevestigen .................................................. ................................ 17

Beheersen van een Fase (BF) ................................................................ .................................. 18 3.5.1

BF3 - Projectissues verzamelen ...................................................... ................................ 18

3.5.2

BF4 - Projectissues beoordelen ...................................................... ................................ 18

3.5.3

BF8 - Projectissues escaleren ........................................................ ........................ 18

3.5.4

BF9 - Afgerond Werkpakket ontvangen ............................................. ................................ 19


1.1

2

Whitepaper: Prince2 en Architectuur Inhoudsopgave

3.6

3.7

3.8

3.9

4

Managen productoplevering (MP) ............................................................. ............................. 19 3.6.1

MP1 - Werkpakket aannemen ........................................................ ........................ 19

3.6.2

MP2 - Werkpakket uitvoeren ......................................................... ......................... 20

Managen faseovergangen (MF) ................................................................ ................................. 20 3.7.1

MF1 – Faseplan opstellen.............................................................. .............................. 20

3.7.2

MF3 – Business case actualiseren .................................................... ................................ 20

3.7.3

MF6 – Afwijkingsplan opstellen ...................................................... ................................ 21

Afsluiten van een project (AP)................................................................ (AP) ................................. 21 3.8.1

AP1 – Project afbouwen ............................................................... ............................... 21

3.8.2

AP2 – Vervolgacties identificeren ................................................... ................................ 22

Opstellen van een plan (PL) ................................................................ .................................... 22 3.9.1

PL2 - Producten definiëren en analyseren ......................................... ................................ 22

3.9.2

PL3 - Activiteiten en afhankelijkheden identificeren id ........................... 23

3.9.3

PL4 - Schatting maken ................................................................ ................................. 23

3.9.4

PL5 - Tijdschema opstellen ........................................................... ........................... 23

THEMA’S MET ARCHITECTUUR ARCHITEC BINNEN PROJECTEN ............................. 24 4.1

Inrichting van het project ................................................................ ...................................... 24

4.2

Impact Analyse ................................................................ ................................................................................... 25

4.3

Kwaliteit ........................................................................................... ................................ ........................... 26

4.4

PSA ................................................................................................ ................................ .................................. 27

4.5

Afwijkingen n op de architectuur ............................................................... ............................... 29


1.1

3

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.

1.1

Doel van het document

Het doel van dit document is om te beschrijven hoe het werken onder architectuur volgens DYA het werken met Prince21 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 projectleiders2 en architecten3 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 architecten4 anderzijds. Voor projectleiders wordt duidelijk op welke manier architectuur inhaakt op de uitvoering van een 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 van een 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 09539107-8-4. 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. Sogeti Nederland B.V. juli 2009

1.1

1

Whitepaper: Prince2 ce2 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 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 aanpassingen 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 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 IS 0-9539107-8-4. 4. Dit boek is eigendom van Key Result. [2] “De kleine Prince 2”, vierde gehele herziene editie; Mark van Onna, Ans Koning; Academic Service; ISBN 90 395 2450 5. [3] “DYA®: Snelheid en samenhang in businessbusiness 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 90-72194-62-4; 4; [4] “DYA®: Stap voor stap naar professionele enterprise-architectuur”, enterprise architectuur”, 2004; Martin van den Berg, Marlies van Steenbergen; Ten Hagen & Stam uitgevers; ISBN 9090 440-1121-9 [5] “Project Start Architectuur”, 2007 White paper; Joost Luijpers; www.dya.info [6] DYA®|INfrastructuur, architectuur voor de fundering fundering van de IT, 2007; Daniel Jumelet; Academic Service; ISBN: 9789012124614 / 9012124611


1.1

2

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 www.dya.info. 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.1.1

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.


1.1

3

Whitepaper: Prince2 ce2 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 businessbusiness en ICT-management management steeds meer samen welke businessdoelen de organisatie wil nastreven. De mogelijkheden binnen de ICT bepalen namelijk mede de mogelijkheden voor de organisatie. organi 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 anciële consequenties zijn (in termen van investering, jaarlijkse kosten en baten). Is een business case positief, dan wordt overgegaan tot het opstellen van een concreet projectvoorstel. De uitkomst van deze activiteiten is het projectportfolio; het overzicht icht 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. nagement. 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 Archit 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 projectproject start-architectuur architectuur mee. Een project-start-architectuur project architectuur is een vertaling van de algemene architectuurprincipes en modellen naar een op het project toegesneden kader. Dit kader geeft de concrete standaarden, normen en richtlijnen weer die het project zal hanteren. Ook projectoverstijgende ontwerpkeuzen worden in de projectproject Sogeti Nederland B.V. juli 2009

1.1

4


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 van een 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 Architectuur5, 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 van een 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.


1.1

5


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 just architectuur, just-enough enough architectuur en e de project-start-architectuur. architectuur.

2.1.2

Het architectuurraamwerk

Om de architecturen te kunnen classificeren heeft DYA zijn eigen architectuurraamwerk. architectuurraamwerk. Het vormt als het ware een ladenkast waarin elke architectuur zijn plek krijgt. Het architectuurraamwerk illustreert illustreert dat de architectuur van een 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 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 v de actuele veranderingen binnen de organisatie. Het Architectuurraamwerk van DYA®, zoals hieronder in Figuur 2 afgebeeld, heeft als doel om relevante deelarchitecturen deelarchitecturen 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. 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 bedrijfsdoele wil bereiken, de processen die hiervoor nodig zijn en de manier waarop de uitvoering van die processen is georganiseerd. 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 informatieinformatie uitwisseling binnen de organisatie ondersteund wordt. De technische architectuur vormt het kader voor de technische infrastructuur van de organisatie6: de servers die die de procesverwerkende capaciteiten leveren, de middleware die ondersteunende, generieke ondersteuning aan bedrijfsapplicaties verzorgen, storage voor de (semi-)permanente (semi )permanente opslag van data, de netwerken voor het transport van deze data tussen de verschillende 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 aamwerk gebruiken dat voor hen het meest geschikt is. Sogeti Nederland B.V. juli 2009

1.1

6


Figuur 2 Architectuurraamwerk De verticale as van het raamwerk laat zien dat architectuur opgedeeld kan worden in drie abstractieniveaus: Algemene principes, principes Beleidslijnen en Modellen. Modellen Het hoogste abstractieniveau van architectuur is het niveau van de algemene principes. Deze weerspiegelen de gezamenlijke visie van businessbusiness en ICTICT topmanagement. 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 rbeelden 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 v 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 es 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 tappen 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 n 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


1.1

7


speelt de grafische vormgeving vaak een grote 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

Projecten 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 van van een strategie een langere termijn perspectief heeft. Het doorvoeren en bestendigen van een strategie is een kwestie van enkele jaren. Projecten 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 bedrijfs 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 deeloplossing die het project oplevert past in het grotere geheel. Deze architectuurrequirements gaan over niet-functionele niet aspecten. Dit zijn extra requirements ter aanvulling op de gebruikelijke drieluik van requirements: business-,, useruser en systemrequirements. Figuur 3 geeft dit schematisch weer.


1.1

8


Algemene requirements

Project

Korte termijn

Referentie Architectuur

Principes en modellen toegespitst op project

Architectuur requirements

Principes en modellen

Lange(re) termijn

Oplossing

Projectspecifieke requirements Impact analyse

Figuur 3 Relatie architectuur en projecten

2.2.1

Projectarchitect

Om de afstemming tussen het architectuurperspectief en het projectperspectief te krijgen wordt aan elk project de rol7 van Projectarchitect 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.

2.2.2

Controlling architect

Een andere rol8 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 Project 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.


1.1

9


2.2.3

Escalatie naar de architectuurraad

In de visie van DYA® werkt een architect in een organisatie voor een opdrachtgever. De e 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 voor de genoemde gebiedengebieden principes en modellen op te stellen en relevante standaarden te selecteren. Als het businessdoel daadwerkelijk in programmaprogramma 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 van een PSA.

Opdrachtgever

Projectmanager

Architect

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 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, ‘ architectuurarchitectuur management’ 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

Projectmanager

Figuur 5 De architectuurraad


1.1

10


De voornaamste taken van een 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.


1.1

11

Whitepaper: Prince2 ce2 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. ince2. Figuur 6 geeft deze weer. SP

OP Opstarten van een Project

Sturen van een Project

IP Initiëren van een Project

BF Beheersen van een Fase

MF Managen Faseovergangen

AP Afsluiten van een Project

MP Managen productoplevering

PL

Opstellen van een plan

Figuur 6 Processtructuur Prince2 Onderstaande tabel geeft een overzicht van die punten waarbij de relatie van architectuur met Prince2 tot uitdrukking komt. Proces OP - Opstarten van een project

IP - Initiëren van een project

SP - Sturen van een project

BF - Beheersen van een fase Sogeti Nederland B.V. juli 2009

Relatie met architectuur • 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). • Architectuurrequirements via de PSA; • Controlling architect opnemen als reviewer; • Uitvoeren van de Impact Analyse; • Architectuurraad als gesprekspartner Stuurgroep; • Architectuur in de projectrapportage. ctrapportage. • Architectuur als referentiekader opnemen; • Afwijkingen op de architectuur behandelen; • Afwijkingen op de architectuur als open issues of vervolgactie definiëren. • Goedkeuring van de architect van een 1.1

12

Prince2 en Architectuur Prince2 en architectuur

Proces

MP - Managen productoplevering

MF - Managen faseovergangen

AP - Afsluiten van een project

PL - Opstellen van een plan

Relatie met architectuur afgerond werkpakket; • Afwijkingen op de architectuur als projectissues; • Advies van de projectarchitect bij de uitvoering van werkpakketten; • Review van producten door de controlling architect. • 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. • 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; • 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 van een 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




• Opstellen Projectvoorstel (OP4) • Architectuurparagraaf • Projectaanpak definiëren (OP5) • Invloed van architectuur • Plannen Initiatiefase (OP6) • Impact analyse • PSA PL






Figuur 7 Opstarten van een project


1.1

13


3.2.1

OP4 – Projectvoorstel opstellen

Onderdeel van het werken onder architectuur is het vaststellen van de taken, bevoegdheden en verantwoordelijkheden van een architect. Vanuit architectuurstandpunt hoort daar bij dat de projectarchitect projectarchitect geraadpleegd moet worden bij het opstellen van het Projectvoorstel. Onderdeel van het opstarten van een project is het opstellen van een Projectvoorstel. 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 Projectvoorstel een aparte architectuurparagraaf opgenomen opg 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-, 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 projectt bewust níét onder architectuur wordt uitgevoerd, wordt in deze paragraaf verwezen naar de Management letter.

3.2.2

OP5 – Projectaanpak 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 generieke voorziening voor de hele organisatie oplevert eerder uit te voeren dan andere delen van het project.

3.2.3

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 3.9.


1.1

14


3.3

Initiëren van een project (IP)

Tijdens de projectinitiatiefase wordt de fundering voor het project neergelegd in de vorm van het Project 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







• Kwaliteitsplan opstellen (IP1) • Achitectuurrequirements (PSA) MP • Controlling architect als reviewer Managen product• Business case & risico’s aanscherpen (IP3) oplevering • Uitvoeren Impact Analyse • Projectbeheersing opzetten (IP4) • Architectuurraad • Architectuur in rapportage PL


Figuur 8 Initiëren van een project

3.3.1

IP1 – Kwaliteitsplan opstellen

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 Projectstart-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 projecten 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 Sogeti Nederland B.V. juli 2009

1.1

15


opgezet moeten worden. Ook moet de controlling architect betrokken worden als één van de reviewers bij een kwaliteitsreview.

3.3.2

IP3 – Business case & Risico’s Risic aanscherpen

Eén van de hoofdtaken van architectuur is om inzicht te verschaffen in de samenhang en structuur van de inrichting van een 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 vanweg 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 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 ze Impact Analyse worden afspraken gemaakt tussen de projectleider en de business analist (met de projectarchitect) over inspanning, doorlooptijd en n oplevermoment van de Impact Analyse en over de kwaliteitscriteria. Het inzicht dat uit de Impact Analyse komt 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 Project Initiatie Document (PID).

3.3.3

IP4 – Projectbeheersing opzetten

Bij dit proces worden n de controlepunten en de rapportages voor het project vastgesteld. In de paragraaf “Architectuur en projecten” (paragraaf 2.2) 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 van een Project (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.


1.1

16


SP



• Projectinitiatie autoriseren (SP1) IP • Architectuur als BF referentiekaderMF opnemen Initiëren Beheersen Managen • Ad hoc sturing geven (SP4) van een van een Fase• Afwijkingen op de architectuur Project Fase overgangen • Projectafsluiting bevestigen (SP5) • Afwijkingen als open issue en/of vervolgacties



PL


Figuur 9 Sturen van een project

3.4.1

SP1 – Projectinitiatie 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.

3.4.2

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.

3.4.3

SP5 - Projectafsluiting 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.


1.1

17


3.5

Beheersen van een 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 producten de goedkeuring van de controlling architect te hebben. SP




• Afgerond werkpakket ontvangen (BF9) • Goedkeuring architect

PL





• Projectissues verzamelen (BF3) • Projectissues beoordelen (BF4) • Projectissues escaleren (BF8) • Afwijkingen op de architectuur


Figuur 10 Beheersen van een Fase

3.5.1

BF3 - Projectissues verzamelen

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 van een review. Afwijkingen worden namelijk doorgaans oorgaans 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.

3.5.2

BF4 - Projectissues beoordelen

Het hierboven geregistreerde projectissue 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 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.

3.5.3

BF8 - Projectissues escaleren

Vanuit hier wordt, in het kader van de architectuur, eventuele eventuele afwijkingen op die architectuur als projectissue geëscaleerd naar de Stuurgroep. Hiertoe wordt een


1.1

18


Afwijkingsrapport opgesteld. De Stuurgroep zal naar aanleiding hiervan de discussie met de Architectuurraad aangaan.

3.5.4

BF9 - Afgerond Werkpakket ontvangen

Bij het ontvangen van een 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

Managen 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





• Werkpakket aannemen (MP1) • Werkpakket uitvoeren (MP2) • Advies op basis van PSA • Kwaliteitsreviews


PL




Figuur 11 Managen productoplevering

3.6.1

MP1 - Werkpakket aannemen

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.


1.1

19


3.6.2

MP2 - Werkpakket uitvoeren

Tijdens de uitvoering van een 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 itect 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 trokken wordt bij de uitvoering van de kwaliteitsreview.

3.7

Managen 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






PL



• Faseplan opstellen (MF1) • Kwaliteitsreviews • Business case actualiseren (MF2) • Raadplegen • Afwijkingsplan opstellen • Afwijkingen op de architectuur


Figuur 12 Managen faseovergangen

3.7.1

MF1 – Faseplan opstellen

Onderdeell 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. voorzitter. Dit moet in het faseplan opgenomen worden.

3.7.2

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 Sogeti Nederland B.V. juli 2009

1.1

20


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.

3.7.3

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 van een 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


PL







• Project afbouwen (AP1) • Architectuurcriteria • Afwijkingen als projectissues • Vervolgacties identificeren (AP2) • Afwijkingen op de architectuur


Figuur 13 Afsluiten van een project

3.8.1

AP1 – Project afbouwen

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.


1.1

21


3.8.2

AP2 – Vervolgacties identificeren id

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 van een plan (PL)

De essentie voor architectuur bij dit proces 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




• Producten definiëren en analyseren (PL2) • Activiteiten en afhankelijkheden identificeren (PL3) • Schatting maken (PL4) • Tijdschema opstellen (PL5) • PSA • Impact Analyse PL






Figuur 14 Opstellen van een plan

3.9.1

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. eitscriteria. 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 van een project opgesteld en vallen dus us 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 3.9.4.


1.1

22


3.9.2

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.

3.9.3

PL4 - Schatting maken

Het maken van schattingen voor activiteiten en producten geldt ook voor de PSA en de Impact Analyse.

3.9.4

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 van een 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 van een –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 daarvan een 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 van een 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.


1.1

23

Whitepaper: Prince2 ce2 en Architectuur Thema’s met architectuur binnen projecten

4

THEMA’S MET ARCHITECTUUR BINNEN BIN PROJECTEN

In dit hoofdstuk wordt de relatie tussen Prince2 en architectuur nogmaals beschreven, maar nu vanuit het perspectief van een 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 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. gehouden. Figuur 15 toont deze aspecten. SP


• Projectbeheersing opzetten (IP4) • Architectuurraad • Architectuur in rapportage OP Opstarten van een Project


• Opstellen Projectvoorstel (OP4) • Architectuurparagraaf • Projectaanpak definiëren (OP5) • Invloed van architectuur

PL




• Projectinitiatie autoriseren (SP1) • Architectuur als referentiekader opnemen



Figuur 15 Inrichting Het Projectvoorstel, dat wordt opgesteld tijdens de opstartfase van een 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 in van de organisatie (zowel op business-, 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 wo 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 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 meegenomen 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. Sogeti Nederland B.V. juli 2009

1.1

24

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 van een 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 van een 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


• Business case & risico’s aanscherpen (IP3) • Uitvoeren Impact Analyse OP Opstarten van een Project


• Producten definiëren en analyseren (PL2) • Activiteiten en afhankelijkheden identificeren (PL3) • Schatting maken (PL4) • Tijdschema opstellen (PL5) PL





• Business case actualiseren (MF2) • Raadplegen


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.


1.1

25


Voor het uitvoeren van de Impact Analyse maakt de business analist en de projectarchitect afspraken met de projectleider over inspanning, doorlooptijd en e 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 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 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 van een Project • Faseplan opstellen (MF1) • Kwaliteitsreviews




• Kwaliteitsplan opstellen (IP1) • Achitectuurrequirements • Controlling architect als reviewer


• Kwaliteitsreviews op producten

PL



• Project afbouwen (AP1) • Architectuurcriteria

• Afgerond werkpakket ontvangen (BF9) • Goedkeuring architect


Figuur 17 Kwaliteit De kwaliteitsnormen bestaan bij het werken onder architectuur niet alleen meer uit de eisen die de klant en de leverancier stellen. stel 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 et managen van een 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


1.1

26


aan deze reviews en de projectarchitect kan zelfs voor sommige van deze reviews de voorzitter zijn.9 Bij het Managen 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 2.2.3. 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 (Project Start Architectuur) is een document, waarin de architectuur is beschreven zoals deze geldt bij de start van een 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 van een 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 2.2.2 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. Sogeti Nederland B.V. juli 2009

1.1

27


SP


• Kwaliteitsplan opstellen (IP1) • Architectuurrequirements (PSA) OP Opstarten van een Project





• Projectissues escaleren (BF8) • Producten definiëren en analyseren (PL2) • Activiteiten en afhankelijkheden identificeren (PL3) • Schatting maken (PL4) • Tijdschema opstellen (PL5) PL



Figuur 18 PSA De PSA wordt opgesteld op basis van het projectvoorstel. De PSA 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 4.3. 4.3. 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 za 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 tgevoerd 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 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 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 4.5.. Afwijkingen die na de discussie tussen deze twee organen (tijdelijk) worden toegestaan, worden vastgelegd in de PSA.


1.1

28


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 van een 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


• Ad hoc sturing geven (SP4) • Projectafsluiting bevestigen (SP5) • Afwijkingen als open issue en/of OP IP vervolgacties Opstarten Initiëren van een van een Project Project




• Afwijkingsplan opstellen • Projectissues verzamelen (BF3) • Projectissues beoordelen (BF4) • Projectissues escaleren (BF8)


• Kwaliteitsreviews op producten

PL

• Project afbouwen (AP1) • Afwijkingen als projectissues • Vervolgacties identificeren (AP2)


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 Sogeti Nederland B.V. juli 2009

1.1

29


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 reparatiewerkzaamreparatiewerkzaam heden 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 ojectleider om deze vervolgactiviteiten goed te beleggen. Hierbij heeft hij ondersteuning van de Stuurgroep en de Architectuurraad.


1.1

30

WHITE PAPER PRINCE2 EN ARCHITECTUUR

Recommend Documents