Pagina {1}

Corporate

Portfolio Management

CPM - DIY

{www.accolades.nl}

Versie : 1.0

Datum : 31 oktober 2012

Pagina {2}

Verantwoording

Het schrijven van een document bedoeld voor een IT afdeling brengt een vervelend aspect met

zich mee, namelijk het feit dat de tekst hinderlijk gebruik maakt van de Engelse taal. Het

Nederlandse taaldomein heeft “gekozen” om vele zelfstandig naamwoorden niet te vervangen

door een term met dezelfde lading. Om dit document toch zo leesbaar mogelijk te maken, is er

een poging ondernomen om de termen die geen lading verliezen in het Nederlands wel te

vertalen. Hierbij zijn toch enkele uitzonderingen, die ik apart hier wil benoemen:

Assessment – Een korte evaluatie van een bedrijfsonderdeel of proces ten einde de huidige

status te achterhalen. Alhoewel evaluatie een prima vertaling kan zijn, is de Engelse term

duurder en dus gangbaarder.

Asset – een fysiek onderdeel van de IT infrastructuur, dus zowel hard- als software als

middleware.

Business – de gebruikersorganisatie als afnemers van ICT diensten, in het Nederlands ook wel

de eindgebruiker genoemd.

Business case – een bedrijfsplan waarbij de voor en nadelen van een bepaald idee worden

uitgewerkt. Tevens worden hier de kosten en de opbrengsten van het uitwerken van het idee

opgeschreven. Afhankelijk van het proces of status van het idee/project is deze uitvoeriger,

accurater en gedetailleerder.

Business Unit – een onderdeel van de gebruikersorganisatie is de afdeling. Echter wordt in het

Nederlands een afdeling eerder gezien als een kleine club mensen tot zo'n 100 man. Een

Business Unit is een verzameling van afdelingen gericht op het ondersteunen van een bepaalde

dienst of markt.

Deliverable – Het op te leveren stuk werk van een persoon, specifiek beschreven in termen van

tijd, kwaliteit en doel. Dit kan een stuk geschreven code zijn voor een applicatie, een document

of een hele service.

Framework – Het kader waarbinnen gewerkt wordt, vaak ondersteund door een specifieke

methode of techniek.

FTE – Fte staat voor fulltime-equivalent, waarbij dit gebruikt wordt als rekeneenheid om de

inzet van personeel uit te drukken. Één FTE is een volle werkweek van 40 uur.

Governance – Het overkoepelende geheel van processen en goedkeuring t.b.v. het besturen van

projecten. Het staat voor 'behoorlijk bestuur' en geeft de mate van beheersing aan voor het

goedkeuren van projecten.

Resourcing – Het geheel van aanvragen, goedkeuren en bemannen van een proces of project.

Een resource is een zelfstandig (?) in te zetten persoon, gekwalificeerd voor de taak.

Roadmap – Een document die de toekomstige functionele wijzigingen van een applicatie of

service beschrijft. In het Half-Nederlands ook wel Releasekalender genoemd.

Pagina {3}

Service – Letterlijk "een dienst", hier meer bedoeld als "functionaliteit die via verschillende

manieren gebruikt kan worden". Een gemakkelijk voorbeeld is je e-mail als service. Deze kun je

via het internet, via je telefoon of via je laptop (Outlook of Thunderbird) lezen, maar blijft

dezelfde service.

Triggers - Externe factor die een proces in gang zet.

Bovenstaande lijst is niet volledig. Per slot van rekening wordt in MS Word ook niet elke Engels

woordje bekroond met een rode golvende streep eronder. Echter zal in het verdere vervolg de

typische Engelse termen toch in vet gemarkeerd worden, een opmerking die ik in de loop van

het schrijven van het boek vaak vervloekt heb.

Daarnaast zijn er vele Engelse termen geaddopteerd in de Nederlandse taal. Het kan zijn dat

deze woorden een blindheid met zich meebrengen. Woorden als input, review, managen of

planning worden niet vet gemarkeerd.

Pagina {4}

1. Verantwoording (of voorwoord)

Introductie 2. Inhoudsopgave

3. CPM leeswijzer (of opzet boek)

4. Deel 1 CPM algemeen

ICT uitgelegd

4.1 Drie Domeinen

4.2 Acht Processen

4.3 Legenda

4.4 Werkgebieden

4.5 CMMI volwassenheid

4.6 Organisatie ICT

4.7 Projectmanagement

4.8 Hulpmiddelen

4.9 Stellingen

5. Deel 2 CPM Processen

Idee Portfolio

5.1 Idee Portfolio Management

5.1.1. Vaststellen visie en strategie

5. 1.2. Aannemen van ideeën

5. 1.3. Doelen en ideeën uitwerken naar programma's en projecten

5. 1.4. Prioriteren van programma's en projecten

5.2 Project Portfolio Management

Project Portfolio

5.2.1. Vaststellen projectenkalender

5.2.2. Maken van portfolio beslissingen

5.2.3. Bijwerken en rapporteren status portfolio

Pagina {5}

5.3 Service Portfolio Management

Service Portfolio

5.3.1 Opname service in portfolio

5.3.2 Opstellen release kalender

5.3.3 Maken Portfolio beslissing

5.3.4 Bijwerken en rapporteren status portfolio

6. Deel 3 Assessment

Assessment

6.1 Opzet assessment

6.2. Volwassenheidsniveaus

6.3 Assessment vragen

6.4 Assessment score

7. Deel 4 Business case

Business Case

7.1 Management samenvatting business case

7.2 Kosten en baten kwantificeren per CPM proces

8. Deel 5 Implementatie

Implementatie

9. Deel 6 Bijlagen

9.1 Bijlage A Leeslijst

9.2 Bijlage B Prince2

Pagina {6}

“Maleisië, ” zei de vrouw terwijl ze de krant opvouwde.

“Maleisië?” de man keek niet eens op en nam rustig nog een slok van zijn zwarte koffie.

“Ja….Maleisië!” en de vrouw keek hem met een glimlach aan.

“Lijkt je dat niet leuk?”

De man keek terug en dacht even na.

“Met alle kinderen natuurlijk” vroeg hij retorisch.

“Uiteraard”, beaamde de vrouw. Ze sloeg haar armen over elkaar alsof ze hem uitdaagde om

maar meteen met het beste argument te komen om het pleit al direct in haar voordeel te

beslechten.

“Volgend jaar?” vroeg hij.

“In het voorjaar lijkt me het beste seizoen.” Knikte ze langzaam.

Hiermee verraadde ze niet alleen de zin in de reis met bijpassend doorzettingsvermogen, maar

ook dat ze een voorsprong op hem had door reeds onderzoek hiernaar gedaan te hebben.

Dus gooide hij er maar het beste tegenaan: “…..wat kost dat?”

“De vlucht is het duurste, dan nog overnachtingen die we in kosten kunnen beperken, het

vervoer en natuurlijk het eten wat bijna niets kost.” Antwoordde ze vastberaden. “Als we nu

boeken, kosten de vliegtickets nog geen 4.000 euro.”

“Weet je zeker dat je volgend jaar al wilt?” Nu begon hij een beetje te glimlachen. Net als die boer

met kiespijn.

“Volgens mij als we een paar maanden goed op onze uitgaven letten is dat makkelijk haalbaar.”

Knikte ze vastberaden.

“Hmmmm…” was zijn niet overtuigende antwoord.

“En voor zo’n gave reis is het natuurlijk heel motiverend om een paar maandjes wat rustiger aan

te doen.” Haar stem klonk niet minder standvastig. “Borneo, de orang-oetangs, prachtig oud oer

regenwoud, palmboomstrandjes en natuurlijk het duiken in het rif……”

“Maar of we in het voorjaar al voldoende hebben is de vraag…..” Onderbrak hij haar voorzichtig

enthousiast.

“Dat kunnen we toch nu uitrekenen?” vroeg ze, terwijl ze naar een pen en papier zocht.

“Grootste uitgave?” terwijl ze hem aankeek.

“Hypotheek,” kwam resoluut het antwoord. Dat was een dooddoener.

“Bijna 40% van ons inkomen gaat op aan deze hut, “ knikte hij begrijpend. “En dan heb ik het niet

over gas, water en elec. Of over de verzekeringen die erbij horen.”

Pagina {7}

“En als je toch alles opschrijft, kun je eten, krant, kleren, telefoon, school, de poets, auto, sporten

van de oudste twee, hun zakgeld en de gemeentebelasting er ook wel bijschrijven.” Somde hij op,

terwijl zij een behoorlijke lijst inmiddels onder elkaar schreef. Hij noemde uit zijn hoofd de

bedragen op. De gemeentebelasting ook, wat haar verbaasde. Die was echter net

binnengekomen, dus dat immense bedrag stond nog op zijn netvlies gebrand. Zelfs over een

aantal maanden verspreid bleef het veel.

“Sjessus.” Zei ze, terwijl ze alle getallen optelde. “Daar blijft niet veel van over.”

“Nee,” beaamde hij, “en dan gaat de rest natuurlijk op aan allerlei ander dingetjes waar we nu

geen post voor hebben. Bijvoorbeeld kado’s, boeken, CD’s, eten voor de hond en meer van dat

soort dingetjes.”

“Hmmmm…..” Was nu haar tekst. Ze zag het voorjaar volgend jaar verschoven worden naar

voorjaar over drie jaar.

“Maar dit is nog zonder dat we zuinig doen.” Begon ze hoopvol.

“Zeker,” knikte hij, “maar vink eerst eens de dingen af waar we simpelweg niet op kunnen

bezuinigen. Zoals de hypotheek, daar kun je heel lang naar kijken, maar die 40% zijn we zeker

kwijt….. Ik neem aan dat we er niet voor hoeven te verhuizen?”

Ze keek lachend naar buiten. Daar had ze iets te lang voor in de tuin gewied om hier een

antwoord op te geven dat binnen de grenzen lag van een gesprek zonder ruzie.

“Daar heb ik eigenlijk een spreadsheet voor nodig.” Terwijl ze snel de vinkjes zette en de getallen

optelde. “Maar grof gezegd is zo’n 75% vaste kosten.”

“Da’s best veel.” Knikte hij fronsend terwijl hij op zijn kop een vlugge controle deed in de hoop

en tegen beter weten in, dat ze ergens naast zat.

“En dan is de rest niet zomaar te schrappen, maar wel te verminderen.” Hierbij ging ze een voor

een alle variabele posten langs. “Zoals schoenen. Daar kun je niet op bezuinigen al had je het

graag.”

“Kinderschoenen niet nee.” Hiermee beseffend dat dit een opmerking op het randje van einde

gesprek was. “En besef,” ging hij verder, “ dat met dit plan wel die nieuwe platte tv van de baan

is.”

Ze keek op met een herkenbare uitdrukking.

“Dat geeft niet…….” vervolgde hij, “ als we het maar beseffen en er bewust voor kiezen. Ik denk

namelijk dat een tv minder leuk is, dan zo’n gave reis.”

“Dan gaan we eens een seizoentje minder inzetten op kleding. ” En met een streep sneuvelde de

eerste post. “Ik ga uitkomen met het eetgeld of zelfs proberen over te houden. Niet meer uit eten,

maar daar besparen we niet eens zoveel mee. En gewoon eens niet alles kopen wat we zien.”

“Wat doen we met de auto?” Vroeg zij.

“Tsja…” Een hekel punt vond hij. “Hij doet het nog wel”

Pagina {8}

“Deze week…..” knikte ze. “Hoeveel was die laatste reparatie ook al weer?”

“800 Euro.” Zuchtte hij diep. “Het lijkt wel een bodemloze put, maar vervanging is vaak zo duur”

“Zullen we daar eens een nieuwe berekening op loslaten?” Vroeg ze niet bijzonder enthousiast.

De vorige exercitie was niet echt uitgelopen op een feestje. Knopen doorhakken was best

moeilijk, maar dit leek toch wel een continue bodemloze put.

“Waar komen we dan op uit?” Vroeg hij na wat gestreep en getel.

“Het najaar.” Glimlachend keek ze naar hem op.

“Regentijd….. maar beter dan onze herfst”

Pagina {9}

Voorwoord

Herkenbaar? En dan heb ik het niet over de interactie tussen hem en haar (alhoewel hier ook

enige mate van herkenning in kan zitten). Dan heb ik het over het stellen van doelen en hoe deze

bereikt kunnen worden. Over de middelen die je voorhanden hebt om deze doelen te behalen en

op de wijze waarop je een realistische einddatum kunt bepalen. Maar niet onbelangrijk is het

gewone leven dat dagelijks aan je voorbij gaat, terwijl er grote beslissingen gemaakt kunnen

worden.

Wanneer je een gezin voorstelt als bedrijf, zijn er grote parallellen te trekken. Hierbij gelden

dezelfde zaken, maar dan vaak in het klein. Het financieren van een nieuwe auto, het moeten

kiezen tussen de mooie spiegels in de badkamer en de aanleg van een tuinhuisje of het inzicht

dat een groot deel van de uitgaven van je salaris opgaat aan dingen waar je geen fluit aan kunt

veranderen op korte termijn.

Steeds meer bedrijven zijn bezig om hun verandercapaciteit boven tafel te krijgen. Dit gebeurt

niet alleen op basis van financiële feiten, maar ook op efficiëntie en effectiviteit. Ook de

bedrijven hebben veel budget nodig voor het pure operationele werk om hun klanten te

bedienen. Bedrijven zijn vaak (maar zeker niet altijd) bewuster aan het nadenken wie ze willen

zijn of welke doelen ze willen bereiken. De keuzes die een bedrijf hiervoor maakt, moeten meer

en meer in lijn zijn met de visie en doelen die ze stelt. Het inzetten van baliepersoneel of het

investeren in een goede internet omgeving kunnen elkaar uitsluiten, als er maar budget is voor 1

van deze twee. Goede voorbeelden zijn te vinden in de studie van Jim Collins in zijn bestseller

Good to Great (Collins, 2004). Hierin wordt beschreven dat de excellente bedrijven in zijn studie

gericht bezig zijn geweest om dat ene ding te doen waar ze heel goed in zijn. In zijn boek wordt

dit het Egel-principe genoemd.

Ook bedrijven hebben hun "auto". Het is dat ene systeem of dat langlopende project waar ze

maar steeds niet de knoop doorhakken of deze nu gestopt moet worden of niet. Ook daar is het

vaak ongewis of deze keuze te stoppen beter is dan het doormodderen met de huidige situatie.

Menselijke psychologie is hier ook een factor van belang. Bij niets doen weet een persoon vaak

wel wat het nu heeft, stoppen is een stap in het onbekende.

Het verhaal vertelt ook over de menselijke neiging om beslissingen achteraf goed te praten. Hoe

men kiest voor optie A en een volledig verhaal kan aankleden rond de rechtvaardiging van deze

optie. Totdat er door externe omstandigheden gekozen moet worden voor optie B. Hierna wordt

het proces nogmaals doorlopen, de rechtvaardiging van deze optie, maar dan voor optie B. De

herfst aan het einde is achteraf natuurlijk de beste keuze, terwijl de vrouw graag in het voorjaar

wilde gaan.

Het grote verschil is dat gezinnen vaak iets overzichtelijkere cijfers hebben en dat de

beslissingen binnen een gezin (vaak) uniform, ook wel dictatoriaal, genomen worden. Er speelt

een stuk minder politiek en dit soort grote beslissingen worden genomen onder een soort van

consensus. Bij bedrijven is het boven tafel krijgen van de cijfers vaak een enorme klus. Ook is de

politiek een enorme invloed op de besluitvorming, waarbij het onduidelijk wordt of deze

besluiten nu puur op basis van rationele cijfers gebaseerd zijn of niet.

Pagina {10}

Mijn boek begon met een verhaal over een stel ouders dat haar budget zat te bekijken en te

begroten. Ik had ook kunnen putten uit een rijk arsenaal van krantenkoppen van (wederom)

mislukte projecten, al dan niet in de ICT. De reden hiervoor is het feit dat ik het concept van

portfolio management eerst intuïtief wil neerzetten, voordat deze op de alledaagse wereld wordt

geprojecteerd. Hoe mooi de voorbeelden van mislukte projecten ook zijn, hier liggen vele

oorzaken ten grondslag. Denk hierbij aan slecht project management, slechte risico inschatting,

systematische onderschatting van de werkzaamheden, wijzigende requirements en gebrek aan

vertrouwen tussen klant en leverancier. Vaak is het een combinatie van alle zaken.

Metrolijn van Amsterdam

UWV met haar applicatie debacle

De waterschappen met haar uitbesteding aan Logica

De SS Rotterdam die als woonboot werd ingericht

Dit boek is niet bedoeld om deze oorzaken weg te werken of bloot te leggen. Daarvoor zijn

opleidingen, ervaring, betere methodes en dergelijke voor. Deze projecten waren ongetwijfeld

door goede mensen geleid. De gebruikte methodes zullen niet anders zijn dan de methodes die

gangbaar zijn in andere organisaties. Toch denk ik dat dit boek een bijdrage kan leveren aan het

verbeteren van processen die ten grondslag liggen aan de meeste, zo niet alle projecten en

programma’s.

Specifiek wil ik hier de parallel trekken met een boek dat ik vaak “voorlees” aan een van mijn

dochters. Het betreft een zoekboekje waarin met verschillende thema´s gefotografeerde

objecten gevonden moeten worden. Zoek drie brandweerauto´s, zoek 4 tractors of zoek 5

fietsen. Bij elke pagina is er ook 1 jongetje verstopt, gekleed in een fel rood jasje. Dit is de

terugkerende factor binnen het boek en een kers op de taart voor mijn dochter om te vinden.

Met drie jaar op de teller vindt ze deze nu met haar ogen dicht, maar de eerste keer was

behoorlijk zoeken. De grap hierin zat in de bladzijdes waarin het jongetje niet heel klein getoond

werd over een rode aardbei heen. Nee, de moeilijkste zoekplaatjes waren die waarbij het

jongetje bijna bladzijde vullend zo groot was. Zo groot dat mijn dochter het niet meer kon zien.1

Bij de meeste grote organisaties zijn de boosdoeners vaak dit soort mega-trajecten. Je kunt je

haast niet voorstellen dat een project dat zo belangrijk is voor een organisatie fout kan gaan.

Hypotheek systemen die na 7 jaar bouwen toch niet gebruikt worden, bankorganisaties die bijna

een geheel nieuwe ontwikkelmethode met bijbehorende ontwikkelomgeving proberen te maken

en de legio organisaties die pogen het ERP pakket te misbruiken voor alles wat los en vast staat.

In de meeste opleidingen worden deze zaken vaak heerlijk aangedikt besproken met alle

studenten die in een collegezaal hopen ooit in de positie te komen het slimste jongetje (of

meisje) binnen zo'n bedrijf te worden. In zo'n uitgewerkte case is de werkelijkheid enorm

ingedikt om te kunnen passen in de gestelde college uren. Daarna is het vrij eenvoudig te

bepalen waar het binnen een organisatie fout is gegaan. De meeste studenten verbazen zich

erover dat mensen in de specifieke gevallen zo blind hadden kunnen zijn. Toch heeft Jim Collins

1 Bekijk hiervoor ook de video op youtube (Selective Attention Test) waarbij je het aantal keren dat een

basketbal wordt overgegooid moet tellen. De eerste keer zul je versteld staan, kan ik je garanderen.

Pagina {11}

in zijn boek slechts 12 bedrijven gevonden die het predikaat Great kregen, terwijl het aantal

bedrijven dat nooit het Good ontstijgen legio is.

Als laatste signaleer ik nog een discrepantie rond de doelstelling van een bedrijf die van hoger

hand worden bepaald (top-down) en de bottom-up onderbouwing van de plannen van

afdelingen. Een bedrijf bepaalt vaak rond augustus welke budgetten nodig zijn voor het jaar

daarna. De basis hiervan is vaak een afdelingsplan dat het huidige budget pakt en vermeerdert

met een aantal FTE’s die nodig zijn om nieuwe dingen op te pakken. De directie heeft een heel

ander plan, waarbij de onderbouwing niet direct gekoppeld is aan de individuele

afdelingsplannen die ten grondslag hiervoor moeten liggen. De directie kan bijvoorbeeld

bepalen dat er 10% bezuinigd moet worden. De kosten zijn simpelweg te hoog om een gezond

bedrijf in de toekomst te behouden. Deze 10% wordt niet samengesteld uit diverse plannen en

initiatieven vanuit deze afdelingen. De doelstelling om 10% te bezuinigen wordt vaak juist op

afdelingsniveau uitgevochten omdat daar de realiteit van deze bepaling inzichtelijk wordt. Dit

komt voor een deel omdat dit niet in de aard van de lijn organisatie zit. Het draait zoals het moet,

men is vaak heel druk met de huidige gang van zaken en heeft zelden tijd om reflectief de eigen

afdeling tegemoet te zien. Daar zijn projecten juist voor.

Vanuit directie komen wezenlijke zaken naar boven als “is het besparen van een miljoen op een

applicatie slimmer dan het vergroten van mijn afzetmarkt?” Vergeet niet dat alle projecten en

programma’s briljante resultaten voorspellen. In principe moet een directie zich kunnen

afvragen of het geld niet beter op de bank gezet kan worden i.p.v. in een project geïnvesteerd

worden. En dan heb ik het dus niet over de diverse miljoenen die gemeentes in Nederland bij

IJslandse banken hebben ondergebracht.

Dit boek geeft een beschrijving hoe beslissingen over het ICT budget binnen een organisatie

verbeterd kunnen worden. Het geeft een raamwerk welke processen er spelen binnen een

organisatie die ten grondslag liggen aan de besteding van ICT budget. Het beschrijft welke

informatie nodig is om tot keuzes te komen, wie deze zou moeten nemen en hoe de informatie

vergaard moet worden.

Maar bovenal geeft dit boek de mogelijkheid om de processen rondom het opzetten en beheren

van project, ideeën en service portfolio's te verbeteren.

Pagina {12}

{Corporate Portfolio Management}

De methode van Corporate Portfolio Management heet Accolades. De accolade is een oud

symbool met diverse betekenissen.

Samenvattend; Een accolade vat de inhoud van een opsomming samen tot een eenduidig

geheel. Het geeft een duidelijke grens aan van wat wel en wat niet bij de samenvatting hoort. Zo

wordt het Project Portfolio Management samengevat als het totaal aan onderhanden projecten

en zijn de drie onderliggende Portfolio’s samen te vatten als de Corporate Portfolio. Vandaar het

logo met de vier accolades. Het Corporate Portfolio omvat het Idee Portfolio, het Project

Portfolio en het Service Portfolio.

Een verzameling; In de wiskunde wordt het gebruikt om een verzameling van objecten weer

te geven. Ook dit is een goede mogelijkheid om naar het Portfolio Management te kijken. Een

afdeling heeft een portfolio of verzameling aan projecten die veranderingen gaat doorvoeren.

Sommige projecten zijn nog niet gestart, enkele zijn onderdeel van een groter programma en

sommige lopen al erg lang. Het blijven allemaal projecten die specifiek voor een afdeling van

belang zijn. Dit betekent ook dat een project mogelijk voor meer dan een afdeling belangrijk is.

Het project behoort dan dus ook tot meerdere verzamelingen of portfolio’s.

De ridderslag; In vroeger tijden werden edelen tot ridder geslagen met behulp van de

accolade. Het is de goedkeuring van de regerend vorst die iemand promoveert tot een hogere

rang. Alhoewel het maar een deel van de totale methode ondervangt, is het goedkeuringsproces

een zeer belangrijk onderdeel van CPM. Het is door middel van het goedkeuringsproces dat een

idee wordt omgezet tot project. Het is ook de goedkeuring die er voor zorgt dat er uiteindelijk

een nieuwe service wordt geïmplementeerd.

Pagina {13}

I. Corporate Portfolio Management

A. Doel Ik ben “opgevoed” vanuit de gedachtegoed dat alles wat ik produceer op (digitaal)papier een

doel moet hebben. Zonder doel ben je bezig met letters op papier te zetten, maar met een doel

ben je bezig om via deze letters iets te bereiken. Zo ben ik ooit een serie vergaderingen, elke

dinsdagochtend van 10 tot 11 bijeengeroepen om betere communicatie te bewerkstelligen,

begonnen met het doel “onszelf op te doeken”. Nodeloos te melden dat de eerste vergadering

voornamelijk gevuld werd met de discussie of dit wel überhaupt een zinvol doel was. Ik ben er

nog steeds niet over uit.

De reden om dit uiteindelijk in boekvorm uit te brengen is puur het feit dat de wijze waarop ik

de afgelopen paar jaar bezig ben geweest met het vakgebied van Project & Portfolio

Management intussen uitgegroeid is tot een zodanig grote hoeveelheid informatie, dat het prima

aangeboden kan worden met een nietje erin. De reden waarom het uiteindelijk een zinvolle

uitgave is (“Ik heb al een boek”), komt door een groot gebrek aan eenduidige terminologie en

methodes die specifiek te maken hebben met het managen van portfolio’s. Het feit dat het

digitaal gebeurt is zowel vanwege de bereikbaarheid als de mogelijkheden. Er zit een wereld van

templates achter deze methode die ik graag ook wil aanbieden, maar dit zal nooit in een

boekwerk kunnen omdat sommige zaken digitaal zijn en blijven. Mijn gedachte is om het boek

dan ook maar helemaal digitaal te doen.

In het nu volgende boek zal ik de term Project & Portfolio Management afkorten tot CPM,

Corporate Portfolio Management. Wat mij betreft zijn de twee namen (en dus de afkorting)

synoniem. De term Project & Portfolio Management is iets meer ingeburgerd en die van

Corporate Portfolio Management (nog) niet. Ik zal Project & Portfolio Management nog wel

gebruiken wanneer ik verwijs naar de applicaties die in de markt zijn gezet ter ondersteuning

van (voornamelijk) project management processen. PPM staat in de komende tekst dus ook voor

de wijze waarop de markt kijkt naar het vakgebied. Dit is een te krappe benadering van het

gebied, CPM zet hier breder op in. Ik zal in dit hoofdstuk uitleggen waar CPM voor staat.

Project & Portfolio Management is over haar initiele hype heen. Het is kort na 2000

geïntroduceerd binnen de ICT en heeft vrij snel daarna een plaats veroverd binnen de buzz-

word community van ICT organisaties. Helaas zijn daarnaast enkele gebeurtenissen ook weer

opgetreden gedurende deze periode. Een ervan is de beperkte houdbaarheid van buzz-words.

De snelheid van Informatie Technologie wordt niet alleen gevoed door vele vernieuwingen,

maar ook door de beperkte interesse van software leveranciers en consultancy bedrijven. Een

aandachtsgebied is maar een beperkte tijd “hot” en zal binnen die tijd of binnen de ICT

gemeengoed moeten zijn of zich snel aansluiten bij en overgaan in de volgende hype. Verder zijn

de meeste bedrijven erachter gekomen dat CPM zich niet laat afdwingen door de implementatie

van een tool. Het oude adagio “ a fool with a tool is still a fool” bleek ook te gelden voor het

PPM gebied. Het implementeren van een goede (of slechte) PPM tool lost het wanbeleid binnen

een ICT afdeling niet op.

Door de software leveranciers werd op PPM ingesprongen na het uiteenspatten van de dot-com

bubble in 2001. Deze periode kenmerkte zich door het (misplaatste) vertrouwen en het daaruit

volgende investeren in luchtkastelen. De eerste insteek voor het positioneren van Project &

Pagina {14}

Portfolio Management was die van de Governance. Grofweg vertaald is dit het aantoonbaar

maken dat de processen rondom het tot stand komen van grote investeringen, waar uiteraard

de grote ICT programma’s onder vallen, juist en eenduidig beschreven zijn en opgevolgd

worden. Hierbij zijn de specifieke zaken die de IT afdeling oppakt verwoord in de term IT

Governance.

Uiteraard laat dit onverlet dat een organisatie keurig via de vastgelegde processen enorm foute

beslissingen kan nemen. Zo zijn er meer dan genoeg voorbeelden waar grote banken of

verzekeraars programma’s met miljoenen budget uiteindelijk afblazen omdat het geheel niet

voldoet, niet te beheren valt of simpelweg niet meer tot de core-business behoort van het

conglomeraat. Hierdoor verplaatste de aandacht binnen het PPM domein naar de slogans voor

effectiviteit en efficiency. Waarbij de efficiency zich opwierp als vakgebied voor de

ondersteuning van projecten onder het motto “de dingen juist doen” en de effectiviteit voor het

uitvoeren van “de juiste dingen”. Dus enerzijds het ondersteunen van projecten en anderzijds

het zorgen voor business alignment. Voor deze laatste term is geen mooie Nederlandse

verzonnen, maar het komt neer op de mate van aansluiting op de wensen en eisen van de

gebruikersorganisatie.

De volgende stap die PPM heeft gezet komt uit de vraag om de lijn organisatie ook binnen het

PPM vakgebied te betrekken. De term PPM begint intussen de lading niet meer te dekken. In een

ideale wereld zou op eenvoudige wijze de kosten van een applicatie of service doorberekend

kunnen worden naar de gebruiker(s). Deze TCO (Total Cost of Ownership) heeft betrekking op

het maken van de applicatie, maar ook alle kosten voor het hebben van de applicatie. Dit

vertaalde zich binnen de PPM wereld als “running the business” en “changing the business”.

Hiervoor moest PPM niet alleen keurig de kosten voor het bouwen kunnen oplepelen, maar ook

uiteindelijk gekoppeld kunnen worden aan alle zaken, zo breed als hardware, database en

stroomgebruik. Dit betekent in de praktijk dus ook koppelingen met Asset Management tools,

SLA hulpmiddelen en ook de helpdesk. Zo werd het PPM vakgebied vrij diffuus, want wat

verstaat men er nu onder? Valt nu de hele ICT organisatie onder PPM?

Wat weer tot gevolg had dat bedrijven geconfronteerd werden met, ook al was het niet altijd

accuraat, een beeld van de mate waarin CAPEX en OPEX verdeeld waren. CAPEX zijn de capital

expenses en de OPEX zijn de operational expenses. Grof gezegd zijn dit de

investeringsbedragen en de operationele kosten, dus de kosten van het project en de kosten om

het draaiend te houden. Uiteraard zit hier een verband tussen, alleen wensen maar weinig

bedrijven deze te zien of te erkennen. Dat er een project opgetuigd wordt voor het bouwen van

een applicatie is vaak direct zichtbaar op het budget van een afdeling. Dit uiteraard aangenomen

dat de kosten gemaakt door de ICT afdeling niet op de algemene grote hoop terechtkomen, maar

doorbelast worden naar de opdrachtgever. In het eerste geval zal de ICT nooit kunnen leveren

wat de bedrijfsvoering vraagt, omdat het vragen vrij is en ze niet direct in hun portemonnaie

voelen wat de consequenties zijn van deze vraag. Dit boek is niet bedoeld om hier uitvoerig op in

te gaan, maar wij verwijzen graag naar het boek IT Success! (Gentle, 2007).

Wanneer er doorbelast wordt naar een afdeling, is de vraag in hoeverre dit doorgevoerd is. Een

applicatie heeft namelijk ook operationele kosten die, overigens door vele studies onderbouwd,

geschat wordt op zo’n 90% van de totale kosten. Deze operationele kosten bestaan uit

monitoring, backups, verstoringen verhelpen, aanpassingen maken en onderhoud. Bij een

volledige doorbelasting van systemen (services, applicaties of assets) gaat een ICT afdeling niet

Pagina {15}

bewegen zonder dat iemand gaat betalen. Functionele wijzigingen, projecten, upgrades van de

database versie of het oppakken van de telefoon bij de helpdesk: alles wordt doorbelast.

Inzage of openheid over de verhouding tussen operationele kosten en investeringskosten, levert

informatie op basis waarvan men kan sturen of keuzes kan maken. Het gevoel dat men goed

bezig is met het ondersteunen van strategische doelen, is wat anders dan zwart op wit zien dat

het slechts 8% is van de totale ICT kosten. Aan de andere kant kan de concurrent op nog geen

3% zitten, wat het weer in een ander daglicht zet. Al met al is er geen goed of slecht hierin.

Gebrek aan informatie of informatie die niet voldoende inzage geeft om te sturen, kan een

organisatie wel enorm parten spelen in de juiste aansluiting tussen bedrijfsvoering en de

ondersteunende ICT afdeling. Om deze informatie te verkrijgen zul je moeten weten wat je wilt

meten. Dit boek heeft als doel hier een antwoord op te geven.

B. Opzet Dit boek is geschreven met als doel om eenduidig vast te leggen wat men verstaat onder

Corporate Portfolio Management. Hiervoor zal in dit boek definities en beschrijvingen gegeven

worden van Corporate Portfolio Management (CPM) zoals accolades dit hanteert in haar

interactie naar en met haar klanten. Bij het definiëren wordt zo duidelijk mogelijk het vakgebied

en alle processen die onderdeel uitmaken van het Portfolio Management beschreven zoals een

organisatie deze ingericht zou moeten hebben.

Er schuilt een enorm gevaar in een boek specifiek gericht op het verduidelijken van een

vakgebied door middel van het beschrijven en definiëren van de verschillende onderdelen. Het

is namelijk zo droog als kurk. Veel van de huidige ICT boeken hebben hier last van en het zal ook

in dit boek niet te vermijden zijn. Het komt bij het vakgebied en hiervoor is bij voorbaat excuses

noodzakelijk, waarvan acte. Echter is voor dit boek gekozen om een valkuil te vermijden,

namelijk een te theoretische aanpak. Wanneer het een puur theoretisch verhaal betreft, waarbij

keurig wordt beschreven hoe de processen heten en wat de definities zijn, wordt de informatie

vaak eenvoudig opzij geschoven. Dit is nadrukkelijk niet het geval voor dit boek. Doel is niet

alleen te beschrijven wat het vakgebied inhoudt, maar ook hoe men kan komen tot een door een

organisatie zelf aangegeven gewenst CPM niveau. Dit boek is dus niet geschreven met puur de

implementatie van een CPM tool in gedachte, maar met het geven van handvatten waar een

bedrijf moet beginnen voor veranderingen. Het doel is een concreet plan te bieden voor

organisaties waarmee direct na het lezen begonnen kan worden in de praktijk.

Het boek begint met het beschrijven van de theorie. Deze beschrijving doet niet onder voor

beschrijvingen van ITIL, Prince2 of welke theorie dan ook. Dus van hoog algemeen niveau

indalend in beschrijving van de processen in details. Hierbij komen rollen, autorisaties, output

en criteria ter sprake die nodig zijn voor het uitvoeren van deze processen. De processen sluiten

op elkaar aan en de consistentie wordt binnen de CPM methode gewaarborgd. Dit is echter het

eerste, theoretische, deel van de methode.

Om de theorie praktisch te maken worden naast het beschrijven van de CPM processen daarom

ook de verschillende stadia van volwassenheid genoemd die hieraan gekoppeld kunnen worden.

Elk stadium, niet perse het hoogste stadium, kan dienen als een gewenste toekomst situatie voor

een organisatie. Voor het gebruik van volwassenheidsniveaus wordt gebruik gemaakt van het

CMMI systeem van het beschrijven van de verschillende niveaus. Dit is een algemeen

geaccepteerde wijze van het beschrijven wat de kenmerken zijn van de mate van

Pagina {16}

professionalisering binnen een organisatie. Het geeft handvatten om te kunnen concluderen

welke zaken aangepakt moeten worden om te groeien op het totale CPM gebied. De processen

sluiten op elkaar aan en de zwakste schakel in de ketting bepaalt de totale sterkte hiervan.

Tevens dient deze CPM methode als basis voor het bijbehorende en toegevoegde Assessment

om het CPM niveau te bepalen. Dit Assessment gedeelte, deel drie van dit boek, is een

vragenlijst die opgesteld is om bij een organisatie de huidige stand van zaken met betrekking tot

haar CPM activiteiten te onderzoeken.

Vanuit het Assessment kan bepaald worden welke stappen noodzakelijk zijn om Corporate

Portfolio Management in te voeren op het door een organisatie gewenste ambitie niveau. Dit kan

in de vorm van het schrijven van een aanpak per onderdeel (proces) waar verbeteringen

mogelijk zijn of een grondige herziening van het geheel. Deze onderdelen worden zo specifiek

mogelijk beschreven en gekwantificeerd voor het onderbouwen van een business case. Deze

business case heeft als primaire doel het invoeren van een PPM applicatie in een organisatie.

Dit moet niet verward worden met een einddoel of verplicht doel voor elke organisatie. Vanuit

het assessment komt per organisatie een eindoordeel over de te bereiken doelen. De reden voor

het beschrijven van een business case voor het invoeren van een PPM applicatie is het feit dat

bij elk proces, op ongeveer het derde niveau van volwassenheid, een noodzaak komt om

informatie en processen te uniformeren over de hele organisatie heen. De PPM applicatie is

genomen als potentieel overkoepelend hulpmiddel ter ondersteuning en het dient als houvast

voor de verbeteringen per proces.

Als laatste onderdeel wordt de implementatie besproken. Deze wordt redelijk generiek opgezet,

wederom omdat voor elke organisatie een ander beeld komt uit de assessment en de daaruit

voortvloeiende business case. Ook hier wordt de invoering van een PPM applicatie genomen als

leidraad en ook hier geldt dat dit absoluut geen verplichte doelstelling is van dit boek (en dus

van een organisatie die CPM wil gaan invoeren).

Dit alles bij elkaar genomen verklaart de aanpak van het boek ook direct de titel, CPM DIY –

Corporate Portfolio Management Do It Yourself. Het boek is bedoeld om gebruikt te worden als

handvat om te bepalen waar je staat, waar je wilt komen en hoe dit te bereiken. Het voorziet de

volgende stap om in de volwassenheid van je organisatie en geeft ook inzage in welke kosten

hierbij gepaard gaan en bespaard worden om deze stap te maken.

C. Theorie

Portfolio

Een portfolio, van het Latijnse portare (dragen) en folium (vel papier), is in het algemeen een

verzameling van werken of verwezenlijkingen van een persoon.

Een portfolio kan gezien worden als een verzameling van objecten. Zoals hierboven is

weergegeven is het een verzameling van werken. De erkende portfolio's zijn werken van

Pagina {17}

personen voor bijvoorbeeld gedrag, ontwikkeling of showcase portfolio's. De hier gebruikte

termen als project portfolio's zijn (nog) geen gemeen goed.

Wanneer we praten over een project portfolio kan dit een verzameling van projecten zijn met

een bepaald kenmerk. Het kenmerk kan verschillen, waardoor ook de kijk op de verzameling

verschilt. Men kan bijvoorbeeld kijken naar projecten die nog niet geautoriseerd zijn. Dit is een

portfolio van ideeën in verschillende voorstadia van project management. Dus in dit geval is het

porfolio alle projecten die nog wachten op goedkeuring. Vaak zijn dit project die verdere

verrijking van informatie nodig hebben om uiteindelijk door de daarvoor geautoriseerde groep

mensen beoordeeld moeten worden.

Maar het portfolio kan ook het totaal aan projecten zijn dat ingediend (en dus eigenaar is van)

een bepaalde afdeling binnen een organisatie. Bijvoorbeeld het totaal aantal projecten dat

uitgevoerd wordt door de afdeling Marketing. Hierbij kan het project al dan niet reeds

onderhanden zijn. Hierdoor krijgt de afdeling inzage in alle projecten die nog in de pijplijn zitten

van de veranderorganisatie en alle projecten die nu onderweg zijn om gerealiseerd te worden.

Een programma kan daarbij ook gezien worden als een portfolio van aan elkaar gerelateerde

projecten.

Om de in productie genomen applicaties te hanteren als een portfolio aan services is nog niet

ingebed in de meeste organisaties. Ook dit kan gezien worden als een portfolio of view op een

verzameling ex-projecten. Een verzameling changes op een bepaalde service of applicatie is ook

een mogelijke portfolio van overkoepelende kleine projecten.

De beschreven voorbeelden zijn klassieke views op de verzameling projecten. Deze klassieke

portfolio's worden als basis gebruikt voor de beschreven CPM methode, zonder ze expliciet te

benoemen. Voor elke organisatie geldt een eigen wijze waarop men naar projecten wenst te

kijken en het is onmogelijk om deze neer te leggen vanuit een theoretisch kader. De methode

geeft wel potentiële portfolio's die een rol kunnen spelen.

De beschreven CPM methode gaat echter verder dan de klassieke indelingen van projecten of

programma's. Het is in de praktijk namelijk vaak gebruikelijk om binnen deze verzamelingen de

beslissingen te nemen. Een portfolio betreft namelijk een hanteerbare hoeveelheid objecten

waarbinnen men beslist. De conflicten zijn direct voelbaar en oplosbaar binnen het portfolio zelf

aangezien alle stakeholders aanwezig zijn en dezelfde belangen hebben. Hierdoor is het

makkelijk schakelen en beslissen. Vaak zijn hiervoor de processen, rollen en autorisaties binnen

een organisatie (lees: programma) op afgestemd. Portfolio overstijgende zaken zijn echter

moeilijker te hanteren. Wanneer een resource tekort wordt bevochten door twee

programma(directeuren) is het moeilijk te beslechten op basis van criteria die verschillend

kunnen zijn tussen beide portfolio's. Het kan ook voorkomen dat er algemene aspecten boven

komen die voor een programma belangrijk zijn, maar niet door het programma zelf opgepakt

kunnen worden. Bijvoorbeeld wanneer een generieke oplossing gebouwd moet worden die niet

slechts de doelen van een programma ondersteunen. Het geschikt maken van een printstraat

voor output naar de zakelijke markt, kan een programma dat gericht is voor het migreren van

portefeuilles naar een financieel pakket dat daar gebruik van maakt, danig in de weg zitten. Het

programma kan dit in de scope krijgen, maar een organisatie kan dit project ook generiek

opzetten buiten het programma. De opdrachtgever zal vervolgens wel er voor moeten zorgen

Pagina {18}

dat dit project ergens onder gebracht wordt. Daarnaast zal de programma manager dit project in

de gaten moeten houden aangezien er een afhankelijkheid is gecreëerd.

{voorbeeld} Een in de praktijk vaak voorkomend fenomeen is het feit dat budgetten gekoppeld

worden aan een afdeling. Dit gebeurt vaak onbewust en is in de meeste gevallen een gangbare

manier om budget aan te vragen. Het nadeel hieraan is dat dit potentiële inefficiëntie in de hand

speelt, omdat een project komende uit de koker van de marketing afdeling mogelijk meer op

gaat brengen dat een project dat door inkoop wordt ingediend. Maar ja, inkoop heeft nog budget.

Ook hier geeft de CPM methode handvatten om dit aan te pakken en te veranderen. Dit is een

van de grootste denkstappen in een organisatie en een mooie meetlat om te achterhalen of een

bedrijf vergevorderd is in het Portfolio Management.

D. Beheer methodes Binnen elk beschreven domein van het Corporate Portfolio Management is er een specifieke

methode die de bovenhand voert in de huidige wijze van opereren binnen de ICT afdelingen. Zo

is in operationele domein bijvoorbeeld ITIL een zeer gerespecteerde wijze van het inrichten van

de beheer afdeling. Al deze methoden zijn gericht op het domein zelf en niet zo zeer op het

vakgebied van CPM. Vanuit de diverse diciplines (business, beheer en ontwikkeling) en de

daarbij behorende methodes wordt bijna verondersteld dat het totale ICT beleid vanuit deze

methode bestuurd kan worden. Vanuit ITIL wordt verondersteld dat eindgebruikers en ICT rond

de tafel zitten om samen de verzameling aan services te bespreken die voor de eindklanten

operationeel zijn. In de praktijk echter zijn ICT-ers de mensen die in een hoek van het gebouw

aan brede tafels met meer dan 1 beeldscherm applicaties aan het bouwen zijn. Het aantal

marketeers dat zich door een 18-jarige IT-nerd laat informeren is zeer beperkt. Daarnaast

worden bij de meeste organisaties meerdere methodes gebruikt. Deze zitten elkaar niet in de

weg, maar zijn eerder te weinig met elkaar verbonden. Dit boek richt zich ook op enkele

standaard methodes en poogt deze overkoepelend bij elkaar te brengen.

Alhoewel informatie technologie een relatief nieuwe studie is, zijn er in de loop van de tijd al

veel theorieën, raamwerken, ideeën en methodes voor ontwikkeld. Deze hebben betrekking op

het gehele vakgebied, van ontwikkeling (OO, IE, etc.) tot aan de hele voortbrengingscyclus (RUP).

Het zou ondoenlijk zijn om deze allen een plek te geven binnen de CPM theorie of zelfs maar te

noemen in dit boek. Echter kan niet verwacht worden dat u, de lezer, deze CPM processen

probeert te introduceren in een bedrijf zonder reeds bestaande aanpak, raamwerk of methode

op in ieder geval een deelgebied. In goed Engels heet dit een green field situation. Die is er

simpelweg nooit.

Daarom zal dit boek ook een basis geven waarin enkele van de belangrijkste bestaande

methodes hun plaats in kunnen vinden. Specifiek is het de bedoeling om Prince2, MSP en ITIL, na

een korte beschrijving, te ‘mappen’ op en te koppelen aan de CPM methode. Deze drie methodes

geven ook goed het niveau aan waar de CPM methode zelf opereert, namelijk als overkoepelend

beheerproces. De CPM methode opereert niet als nieuwe ontwikkelmethode (geen nieuwe

agile) of prioritering techniek.

De bedoeling van de CPM methode is ook niet om een van deze methodes te vervangen, dat zou

weer te omvattend zijn. Tevens dient te worden opgemerkt dat de CPM methode deze methodes

Pagina {19}

wel allemaal meeneemt en aanraakt. Oftewel: de CPM methode betreft alle vakgebieden binnen

de ICT en verbindt deze. Dit is gevisualiseerd in figuur 1.

Figuur 1 CPM en de bestaande methodes

De figuur laat zien dat Corprate Portfolio Management overkoepelend acteert en raakvlakken

heeft met de drie methodes. Deze methodes hebben zelf ook weer raakvlakken met elkaar. CPM

laat de bestaande methodes in takt, maar vult deze raakvlakken zoveel mogelijk in om een

uniforme kijk op het ICT landschap te krijgen.

Bij de beschrijving van deze CPM methode is specifiek gekozen voor benamingen die geen

onderdeel zijn van een bestaand framework om verwarring te voorkomen. Hierbij wordt het

uitspreken van een voorkeur over de verschillende frameworks die een organisatie kan

hanteren vermeden. CPM heeft geen voorkeur voor een onderliggende methode. In het boek

worden er drie gekozen, MSP, Prince2 en ITIL om houvast te geven voor een organisatie bij het

implementeren van de CPM methode. Als er binnen uw organisatie gekozen is voor PMI i.p.v.

Prince2 is het ook zeer goed mogelijk dit binnen het CPM raamwerk te plaatsen. Echter is

gekozen dit niet in dit boek te doen.

Zoals je zult lezen in het volgende hoofdstuk, bestaat de CPM methode uit drie verschillende

domeinen. Voor het beschrijven van de processen binnen een CPM domein zal dus eerst een

korte beschrijving worden gegeven van de methode die de bovenhand voert binnen dat domein.

Vervolgens zal uitgelegd worden wat de overeenkomsten zijn binnen het gebied, maar ook de

verschillen hiertussen. Indien nodig zal ook aangegeven worden wat de mindere kanten aan de

bestaande methode is, zeker in het kader van een overkoepelende methode/view als CPM.

E. Boek indeling Het boek is verdeeld in drie delen, elk met een duidelijk verband met elkaar. Het doel van het

boek is om via een voorgedefinieerde methode elke organisatie zelfstandig een verbeterstap te

kunnen laten maken in haar volwassenheid van het Corporate Portfolio Management.

1. Speelveld CPM

In het eerste deel wordt de algemene theorie beschreven. Wat wordt er verstaan onder

Corporate Portfolio Management, welke processen zijn hierin te onderscheiden en welke

raakvlakken heeft het met andere domeinen. Aan het einde komen alle algemene zaken naar

Pagina {20}

boven die te maken hebben met ICT. Dit zijn zaken waarbij de onschuldige buitenstaander, lees:

een eindgebruiker, een kijkje in de keuken krijgt over hoe een ICT organisatie er uit ziet en

waarom dit zo is. Bijvoorbeeld een mogelijk ICT organogram of een lijst met hulpmiddelen voor

een projectleider.

Dit gaat niet te gedetailleerd omdat dat het doel van dit boek niet is. Ik heb ook niet besloten om

deze dingen, bijvoorbeeld de technieken die beschikbaar zijn voor projectleiders, in bijlagen te

verstoppen. De reden hiervoor is het feit dat binnen het vakgebied van CPM deze taken vaak aan

elkaar gerelateerd zijn. Wanneer een projectleider een Gantt-chart maakt voor zijn planning zal

hij dit periodiek moeten controleren met een lijst van geschreven uren in een tijdregistratie

applicatie. Dit gaat zeker op wanneer op een bepaald moment de processen worden

ondersteund door hulpmiddelen. Naar gelang de relevantie, of de kennis van de lezer, kunnen

deze algemene zaken worden overgeslagen, maar hier zal zeker op teruggevallen worden.

1. Corporate Portfolio Management; Algemene beschrijvingen over waar we het over

hebben als we de methode gaan beschrijven. Daarnaast worden de meest relevante

zaken beschreven die vanuit de ICT invloed hebben hierop.

a. Drie domeinen; In dit onderdeel wordt CPM in beschreven in drie hoofdgebieden

die elk afzonderlijk opereren, maar een duidelijk verband hebben tussen elkaar.

Deze drie domeinen hebben elke een portfolio gebied dat ze bestrijken.

b. Acht processen; Welke processen zijn in deze portfolio gebieden op hoofdlijnen

te onderscheiden en hoe worden deze processen uitgewerkt in het volgende

deel?

c. Legenda; Een uitleg over de kleuren en vormen die gebruikt worden in de

visualisering van het CPM vakgebied.

d. Domeinen; Welke afdelingen hebben invloed op CPM? Of beter: Op welke

domeinen heeft CPM invloed op? In grote organisaties kunnen de rollen bij het

CPM difuus worden, maar hier wordt de grondslag gelegd voor de participanten

bij de CPM methode.

e. Volwassenheidsniveau; Een korte beschrijving van CMMI en hoe deze wordt

gebruikt in het assessment gedeelte van dit boek. CMMI wordt in dit boek

gebruikt om het volwassenheidsniveau van een organisatie te bepalen op het

gebied van processen, rollen, documentatie, hulpmiddelen en financiën. In dit

onderdeel wordt een hoogover uitleg van de theorie gegeven.

f. Organisatie ICT; Dit geeft een globaal overzicht van de verschillende afdelingen

die mogelijk onderscheiden kunnen worden. Hierin wordt de ICT afdeling

geplaatst en de mogelijke rollen die binnen deze afdeling gehanteerd worden.

Deze rollen zullen er expliciet worden uitgehaald omdat in het tweede deel ook

van belang is welke rollen binnen de processen nodig zijn. Tevens wordt de PMO

apart besproken omdat deze een heel eigen entiteit is binnen een programma. De

uitvoering, grootte en output van het PMO is in grote mate bepaald door de

volwassenheid van een organisatie. Als laatste wordt ook de interactie besproken

tussen eindgebruikers en de ICT afdeling. Elke interactie brengt een eigen stroom

aan processen met zich mee, die een plek moet krijgen binnen het CPM.

g. Project Management; Wat doen projectleiders en welke methodes gebruiken ze

om hun taken uit te kunnen voeren? Zonder projectleiders te kort te willen doen

is hier een korte samenvatting van hun belangrijkste taken en werkzaamheden.

Pagina {21}

Deze heb ik voor de CPM methode verdeeld in twee kategorieën, namelijk

planning en rapportage.

h. Hulpmiddelen; Welke hulpmiddelen zijn er om project leiders te ondersteunen

voor hun methodes? Bij elk proces binnen de CPM methode worden mogelijke

tools ter ondersteuning beschreven. Echter zijn de hulpmiddelen die

pretenderen CPM in zijn geheel te ondersteunen uitgegroeid vanuit een

projectleiders perspectief. Daarom worden hier als basis hulpmiddelen

beschreven ter ondersteuning van de projectleiders.

i. Stellingen; Hier worden drie stellingen gegeven die gebruikt worden als

uitgangspunten voor het uitwerken van de CPM methode. Deze zijn als basis

gebruikt voor het uitwerken van de methode.

2. Theorie

In het tweede deel wordt de Corporate Portfolio Management methode in detail beschreven en

de meest ideale situatie geschetst. Het is het theoretische hart van het boek. De drie domeinen,

strategisch, tactisch en operationeel, worden in zijn geheel beschreven. Deze beschrijving bevat

de processen in hun context, inclusief de in- en output voor deze processen. In dit gedeelte

wordt ook de koppeling gelegd naar de belangrijkste theorie die gangbaar is binnen dit domein.

Voor alle domeinen wordt ook specifiek de transitie tussen deze domeinen besproken. Dit is een

apart gedeelte, aangezien niet alleen in theorie de overgang aanwezig is, maar in de praktijk

vaak totaal verschillende groepen hierbij het stokje overnemen.

Per domein wordt vervolgens alle processen benoemd en in detail uitgewerkt.

2. Proces 1-8; de ideale situatie zoals we hem graag willen zien (CMMI-5)

a. Proces; Een beschrijving van het proces en ook de deelprocessen worden

gedetailleerd beschreven.

b. Doel; Waarom moet dit proces doorlopen worden?

c. Input/output; Welke data gaat er in en wat wordt er geproduceerd? Dit gaat

tevens gepaard met een opsomming van de mogelijke criteria die daarbij

gehanteerd moeten worden.

d. Rollen; Wie zouden deze processen moeten uitvoeren en zijn verantwoordelijk

hiervoor?

e. Methodes/tools; Wat zijn gangbare methodes behorende bij dit proces en welke

tools zijn er ter ondersteuning hiervoor?

3. Praktijk

In het derde deel krijgt de lezer de mogelijkheid om de situatie te bepalen van elk van deze

processen op zijn/haar huidige situatie. Hoe kom je er, binnen je eigen organisatie, achter wat de

status is van een proces en welke zaken zijn hiervan van cruciale waarde om te weten. En als ik

die wetenschap heb, wat gaat de CPM methode toevoegen aan mijn organisatie? En als laatste

stap beschrijft het deel hoe de implementatie aan te vliegen.

Het assessment

Het assessment levert concrete, uitgewerkte vragen per CPM proces. Op basis van de

antwoorden kan bepaald worden hoe goed een organisatie een proces heeft uitgewerkt. Hierbij

worden de CCMI niveau's in het eerste deel gebruikt als ijkpunt. Tevens worden de vragen

Pagina {22}

gebruikt als basis voor het schrijven van een business case ter onderbouwing van een voorstel

tot aanpassing van de processen. Uiteraard is dit afhankelijk van de status van de processen van

een organisatie hoe groot de impact is van zo'n aanpassing.

3. Assessment; het bepalen van de huidige situatie d.m.v. het stellen van gerichte vragen

per onderdeel.

a. Score; De uitleg van de 5 assen waarop gemeten wordt en hoe de score daarop te

plotten valt.

b. CPM; Van de 8 bepaalde CPM processen worden de CMMI niveaus van 1 to 5 per

proces beschreven. Hoe zijn deze te herkennen?

c. Vragenlijst; Welke vragen moeten gesteld worden om deze niveaus te bepalen?

De business case

Bij het uitwerken van de business case is het ook zaak dat randvoorwaardelijke zaken worden

benoemd. Denk hierbij aan een minimaal volwassenheidsniveau voor sommige processen.

Uitgangspunt bij de business case is het besparen van kosten, het verhogen van de kwaliteit en

het verlagen van het risico. In dit hoofdstuk wordt voornamelijk ingezoomd op het verbeteren

en dus het besparen van kosten. Bij de implementatie zullen de kosten benoemd worden die

daarbij gepaard gaan. In beide hoofdstukken wordt uitgegaan van twee verschillende

uitgangsposities. Namelijk de situatie dat gekozen wordt voor een Project & Portfolio applicatie

die centraal alle informatie verwerkt en presenteert ten behoeve van projecten. Dit is echter

geen verplichting voor organisaties, zoals ook duidelijk vermeld wordt in het boek. De tweede

situatie betreft puur het verbeteren van bestaande processen zonder de hulp van een PPM

applicatie.

4. Business Case; het categoriseren van de antwoorden van het assessment in potentiële

verbeteringen.

a. Indeling in drie domeinen; Voor het strategische, het tactische en operationele

domein worden de besparingen en verbeteringen gebundeld.

b. Per proces ( de acht CPM processen) wordt gekwantificeerd wat de besparing

oplevert. Ook worden kwalitatieve aspecten benoemd (geen duidelijke

kwantitatieve onderbouwing mogelijk)

c. Business Case; De business case zelf is opgenomen op de website (hiervoor

dien je een account te hebben).

De implementatie

5. Implementatie; Welke zaken moeten uiteindelijk ingericht worden? Waar begin je met

de verbeteringen door te voeren?

a. Scope; Alle zaken op een rijtje. Processen, rollen, criteria, beheer, autorisatie, etc.

b. Aanpak; Enkele algemene opmerkingen over implementaties opgedaan vanuit de

praktijk.

In dit boek is gekozen om het framework eerst te beschrijven om vervolgens in elk volgende

onderdeel weer terug te laten komen als basis. Dit betekent dat de acht processen die

beschreven worden in deel twee in elk onderdeel weer terugkomen met additionele informatie.

Pagina {23}

Om van een specifiek proces dus eerst te weten wat het inhoudt, vervolgens hoe de huidige

status te bepalen valt en vervolgens hoe verbeteringen door te voeren, zal de lezer dus telkens

onderdelen van dit boek eruit moeten lichten.

Nadeel van deze aanpak is de monotone opsomming van de inhoud verdeeld over deze

processen, aan de andere kant is de specifieke rode draad door het boek weer wel duidelijker.

Pagina {24}

Deel 1 Wat doet de ICT?

Op 4 april 1974 kwam een groep mensen bij elkaar......

Bedrijfsfoto Microsoft 1974

I think a nerd is a person who uses the telephone to talk to other people about telephones. And a

computer nerd therefore is somebody who uses a computer in order to use a computer.

Douglas N Adams

Pagina {25}

II. Corporate Portfolio Management

Dit hoofdstuk verklaart eerst de terminologie van de Corporate Portfolio Management methode,

de domeinen, processen en werkgebieden. Vervolgens beschrijft het hoe een ICT organisatie

werkt aan de hand van een voorbeeld. Voor doorgewinterde ICT mensen is het zinvol om de

eerste vier paragrafen te lezen voordat het volgende hoofdstuk opgeslagen wordt. In deze vier

paragrafen wordt de basis gelegd om CPM in het volgende hoofdstuk te beschrijven. De andere

paragrafen zouden in principe in een bijlage gezet kunnen worden, ware het niet dat deze

gebruikt worden in de latere hoofdstukken. Het betreft algemene kennis over CMMI, Project

management en de benamingen van een doorsnee ICT organisatie.

A. Drie domeinen Voor de aanpak van dit CPM boek is het begrip Portfolio Management onderverdeeld in drie

aparte gebieden die een hechte connectie met elkaar hebben. Deze drie gebieden, het drieluik

van Idee , Project en Service Portfolio Management (zie Figuur 2. Idee , Project en Service

Portfolio Management), vormen samen Corporate Portfolio Management. Voor de aanpak van

Corporate Porfolio Management zullen eerst deze begrippen worden besproken en gedefinieerd.

Vervolgens worden deze begrippen uitgezet tegen de diverse domeinen waar ze in spelen. Deze

domeinen worden tevens besproken en uitgewerkt.

Figuur 2. Idee , Project en Service Portfolio Management

{definitie} Portfolio Management – Het beheren of managen van een portfolio betreft het opstellen van en

onderhouden van een verzameling (of doorsnede) aan objecten. Het beheren omvat het

bijwerken van de actuele status van deze objecten in het portfolio en het maken van beslissingen

omtrent deze verzameling. Beslissingen binnen het portfolio zijn bijvoorbeeld welke objecten

opgenomen moeten worden, welke af moeten vallen of het corrigeren van de spreiding in de

Pagina {26}

samenstelling. Het bijwerken van de actuele status betreft het verrijken van de informatie over

de objecten die nodig is om te sturen en beslissingen te nemen.

1. Service Portfolio management

Service Portfolio management – Alle activiteiten noodzakelijk om de huidige set aan Applicaties,

Services en Assets zodanig te beheren, dat de maximale efficiëntie en effectiviteit wordt bereikt

met de daarvoor beschikbare resources, budgetten en tijd restricties. Dit wordt ook wel

‘Running the business’ genoemd of het beheren van de productie omgeving.

Het onderliggende Service Management is direct verantwoordelijk voor de ondersteuning van

de huidige gebruikersorganisatie. Wanneer deze verstoord is, zal direct een issue (service call

of incident) worden gemeld met een hoge graad van urgentie. De nadruk in dit portfolio ligt dus

op het beheer van de huidige ICT omgeving. De processen hierbij die betrekking hebben op het

Porfolio Management richten zich op het maken van beslissingen over de huidige set aan

services, het uitzetten van een toekomstige koers voor deze services en het maken en indienen

van plannen voor elke service. Dit portfolio wordt ook wel het Operationele Portfolio genoemd.

2. Project Portfolio Management

Project Portfolio Management - Alle activiteiten noodzakelijk om de huidige set aan lopende

projecten zodanig te faciliteren, met de randvoorwaarden van beschikbare tijd, resources en

budget, dat deze zo efficiënt mogelijk worden uitgevoerd met een zo hoog mogelijke kwaliteit.

Hieronder valt tevens het beheren van alle activiteiten en risico’s die de prioritering van

projecten t.o.v. elkaar binnen deze restricties beïnvloedt. Doel hierbij is dat de effectiviteit van

de projecten maximaal bijdraagt aan de voor de organisatie gewenste strategische doelen. Dit is

‘Changing the business’.

Het onderliggende Project Management omvat alle processen en activiteiten met betrekking tot

het onderhanden, goedgekeurde werk in de vorm van projecten. Deze projecten zullen in de

toekomst applicaties of services opgeleveren en leveren als zodanig dus input voor het Service

Management. Binnen veel organisaties wordt de vraag gesteld of het ondersteunen van een

ontwikkel- of testomgeving hetzelfde niveau moet hebben als in de gerelateerde productionele

omgeving, die ondersteund wordt door het eerder beschreven Service Management. Dezelfde

problematiek doet zich hier ook voor. Problemen die zich voordoen in dit portfolio hebben geen

directe impact voor de eindgebruikers (business units, divisies, primaire processen). Dit wil

niet zeggen dat de personen in een project niet enorm verstoord kunnen worden en uiteindelijk

aanzienlijke achterstand kunnen oplopen in de projectplanning. Vooralsnog is de impact een

vertraging van de opleverdatum, verhoging van de verwachte kosten, uitstel van de baten en of

planning problemen met resourcing. Dit portfolio wordt ook wel het Tactische Portfolio

genoemd.

3. Idee Portfolio Management

Idee Portfolio Management – Alle activiteiten noodzakelijk om de set aan benodigde,

toekomstige programma’s en projecten zodanig te faciliteren en te prioriteren, dat de

effectiviteit van deze toekomstige projecten maximaal bijdraagt aan de voor de organisatie

gewenste strategische (bedrijfs)doelen. Hier is niet specifiek een mooie term voor, maar op de

keeper beschouwd kan dit ‘Steering the business’ genoemd worden. Ook hier geldt de

restrictie van beperkingen in geld, tijd en resources.

Pagina {27}

Het Idee Management, of bedrijfsvoering, betreft het IT governance gedeelte waarbij alle

processen, resources en budgetten horen, die ten grondslag liggen aan het bepalen van de

bedrijfsstrategie en het laten aansluiten van programma’s en projecten om deze strategie te

verwezenlijken. IT Governance betreft het formele proces rond de keuzes die genomen worden

uit de algemene bedrijfsvoering. Zodra een project of programma officieel van start mag gaan, na

een van te voren strak gehanteerde autorisatietraject, wordt deze in het Idee Portfolio geplaatst.

Het wordt ook wel het Strategische Portfolio genoemd.

{LET OP} De benaming Strategisch, Tactisch en Operationele Portfolio heeft te maken met de termijn voor

in productie name en de realisatiegraad tot deze productie name. Het project van vandaag is de

applicatie van morgen. Het Strategisch, Tactisch en Operationele Portfolio heeft echter niets te

maken met de functionele inbreng zoals deze in een organisatorische hiërarchie zich kenmerkt.

In de praktijk zal de invloed van hoger management in het Strategische Portfolio groter zijn,

maar het is zeker niet zo dat deze portfolio’s strikt genomen ook het organogram

weerspiegelen.

4. Corporate Portfolio Management

Corporate Portfolio Management – Betreft de overkoepelende processen waarin de aansluiting

van en afhankelijkheden tussen de drie bovengenoemde portfolio’s worden beheerd. De

objecten binnen het portfolio zijn in het geval van CPM in drie onderdelen te benoemen,

namelijk Services, Projecten en Ideeën.

Er is geen onderliggend Corporate Management waar een Portfolio gedachte overkoepelend

heen kan vallen. Hierin is dus ook geen specifiek aandachtsgebied waar de focus van activiteiten

ligt. Het enige dat zich kenmerkt in het overkoepelende management is (het gebrek aan) de

aansluiting tussen de drie gebieden. De individuele domeinen worden door een aparte

organisatie gemanaged, elk met haar eigen belangen. Het operationele domein zit in primaire

instantie helemaal niet te wachten op wijzigingen in haar domein vanuit projecten. Toch weet ze

dat dit gaat gebeuren. Het overkoepelende management valt dus te kenmerken door de

gewenste aansluiting tussen de verschillende management domeinen en de daarbijbehorende

methodes.

Pagina {28}

B. Acht Processen De processen die gehanteerd worden in het Corporate Portfolio Management werkgebied,

kunnen ook onderverdeeld worden in Strategisch, Tactisch en Operationeel. Hierbij is het

strategische gedeelte ondervangen in het Idee Portfolio, het tactische in de Project Portfolio en

het operationele in het Service Portfolio.

De onderscheiden hoofdprocessen zijn een achttal groot. Deze kunnen over de domeinen als

volgt verdeeld worden:

1. Strategisch

1. Vaststellen Visie en Strategie

2. Aannemen van ideeën

3. Uitwerken naar Programma’s en Projecten

4. Prioriteren van Programma’s en Projecten

2. Tactisch

5. Vaststellen Tactisch Portfolio

6. Maken Portfolio beslissingen

7. Bijwerken en rapporteren status Portfolio

3. Operationeel

8. Onderhouden Services

Hieraan parallel zijn processen en interactie noodzakelijk op het gebied van financieel en

resource management. Beiden hebben hun eigen focus nodig vanuit de acht processen.

Wanneer deze processen en portfolio’s worden uitgezet tegen de eerder benoemde domeinen

van Bedrijfsvoering, Project Management en Service Management krijgt dit als volgt vorm:

Pagina {29}

Figuur 3 Processen van het Strategisch, Tactisch en Operationeel Portfolio Management

In deel twee van het boek zullen deze drie portfolio’s en hun processen verder worden

uitgewerkt. Vanuit elk portfolio worden de daarvoor benodigde processen beschreven. Deze

processen worden tot in detail uitgewerkt en verrijkt met de volgende details:

1 Proces onderdelen en activiteiten

2 Output en input van het proces

3 Afhankelijkheden tussen de processen en de eerder genoemde domeinen. Hierbij wordt ook

het verband gelegd met de onderliggende methode behorende bij dit domein.

4 Criteria behorende bij de subprocessen, nodig voor het correct verwerken van de gegevens.

Pagina {30}

C. Legenda Binnen de bovenstaande, maar ook alle nu volgende figuren worden enkele visuele vormen

gebruikt. Deze zijn zoveel mogelijk consistent doorgevoerd om voor elk onderdeel een zo

duidelijk mogelijk overzicht te krijgen wat nu wel of niet binnen het domein, proces of subproces

valt.

Resource Management. Aanvragen van resources, het proces van verwerken van resource

aanvragen, welke persoon voor te stellen aan de project manager, hard en soft boekingen van

resources. Het geeft tevens aan hoeveel en wanneer capaciteit per skill beschikbaar is.

Financial Management. Het aanvragen, opstellen, onderbouwen en toewijzen van budgetten.

Tevens hoort hier het bijhouden van de huidige status (het verbruik) van het budget.

Oplevering/fysieke deliverable. Wanneer een proces een tastbare deliverable oplevert, wordt

deze weergegeven via een gesloten vorm met de kleur van het domein waar het proces zich in

bevindt.

Een proces. Alle processen zijn weergegeven als een vierkant. Er is verder onderscheid gemaakt

in de verschillende kleuren voor de domeinen.

Tijd. Vaak gebruikt in de vorm van een trigger (start van een proces). Meestal dus een

periodieke start van een proces.

Pagina {31}

D. Werkgebieden Samengevat is Portfolio Management dus het correct uitvoeren van de projecten met de hoogste

prioriteit en de grootste bijdrage aan de bedrijfsstrategie. Dit is een samenspel tussen de

volgende werkgebieden:

Figuur 4 De werkgebieden die CPM beïnvloeden

De Bedrijfsvoering (business) is de voor IT zo belangrijke eindgebruikers. Deze leveren wensen

en eisen op voor nieuwe projecten, ze leveren opdrachtgevers die uiteindelijk kunnen bepalen

welke richting gekozen moet worden, binnen welke termijn en met welk budget de projecten

moeten opleveren. Ook deze oplevering wordt uiteindelijk door de bedrijfsvoering zelf

goedgekeurd. Hierdoor is de bedrijfsvoering dominant aan de start van projecten en aan het

einde als acceptant.

Service Management is de verzamelnaam van alle operationele processen en resources, die

zowel hun input vanuit de bedrijfsvoering krijgen in de vorm van eisen en wensen, als

zelfstandig invloed uitoefenen in de oplevering vanuit de projecten. Tevens is het Service

Management werkgebied verantwoordelijk voor het ordentelijk invoeren van wijzigingen,

release kalenders en het aanvragen van wijzigingen t.b.v. urgente operationele zaken.

Programma en Project Management is het uitvoerend orgaan voor alle projecten. Het betreft niet

alleen het management van het uitvoeren, maar ook de uitvoering zelf. Zowel de werkgebieden

Bedrijfsvoering en Service Management zullen resources leveren onder toezicht van het

project, waardoor ook deze mensen onder het Programma en Project Management vallen.

Tevens wordt hier expliciet van uitgegaan dat de Project Management Organisatie (PMO)

hieronder valt.

In de figuur zijn tevens de twee belangrijkste restricties opgenomen die binnen het Portfolio

Management een rol spelen, namelijk het budget en de resources. Voor het Resource

Management betekent dit het aanvragen, uitzetten en invullen van de personele bezetting van

projecten. Voor het Financiële Management het opstellen, goedkeuren, verwerken en bewaken

van de aangevraagde budgetten.

Pagina {32}

E. CMMI volwassenheidsniveau Om verbeteringen door te voeren op het gebied van Corporate Portfolio Management wordt

gebruik gemaakt van de volwassenheidsniveau's van CMMI. Dit is inmiddels een vrij klassieke

benadering van het bepalen van de huidige stand van zaken in de ICT. Basis hiervoor is het boek

van Richard L. Nolan (Nolan, Richard, 1974, 1982. Managing the Data Resource Function) dat

enkele jaren later is gebruikt voor een onderzoek bij de Amerikaanse defentie door Humphrey

Watts. Ook hij schreef een boek over zijn onderzoek (Humphrey, Watts, 1988. Characterizing the

software process: a maturity framework).

Algehele doel van het CMMI model is het beschrijven en bepalen van de verschillende stadia van

volwassenheid van een ICT organisatie. Primair was het de bedoeling om de volwassenheid te

bepalen van aanleverende partijen op het gebied van software ontwikkeling, maar intussen is

het als concept succesvol gebruikt op een scala aan ICT gebieden.

Voor het maken van een assessment op het gebied van CPM bij een organisatie wordt ook hier

gebruik van het volwassenheidsmodel gemaakt. Bij het uitwerken van de processen (deel drie

assessment) zijn alle CMMI niveaus per proces beschreven. Deze niveaus geven aan wat de

volwassenheid van een proces is voor een organisatie. Bij het maken van een assessment voor

een organisatie is het essentieel te weten op welk volwassenheidsniveau deze zich op dit

moment bevindt. Vervolgens is het zaak te bepalen op welk niveau een organisatie het graag zou

willen hebben. Zoals alle CMMI toepassingen moet hier opgemerkt worden dat het streven naar

een hoger niveau niet een doel op zich moet zijn. Tevens is de weg naar de verbetering van

belang, in de vorm van kosten en baten, en zeker de prioriteit per proces waarin dit moet

plaatsvinden.

Figuur 5 CMMI niveaus

Om inzicht te krijgen van de vijf verschillende niveaus wordt hier eerst de algemene nievau

beschrijving gegeven.

Pagina {33}

1. Eerste niveau - Initial

Het eerste niveau heeft geen overzicht en is voornamelijk chaotisch. Er zijn geen of weinig

hulpmiddelen, er is geen objectieve afweging tussen de verschillende projecten, geen koppeling

projecten en doelen. Er wordt geen consistente data gebruikt en het is dus moeilijk om

verschillende programma's met elkaar te vergelijken. Het proces is reactief en niet beheerst.

Over enkele van de beschreven processen is twijfel of deze er zijn, zo ja, of ze bewust uitgevoerd

worden.

2. Tweede niveau – Managed

In een proces van niveau twee zijn de diverse losstaande processen beheerst, maar niet

noodzakelijk gelijk. Projecten zijn beschreven, kennen vaste op te leveren documentatie maar

deze zijn niet conform vaste templates. Een project kan haar eigen governance bepalen, zonder

dat hier voor elk project een vaste proces is. Elk proces of procesinstantie kan zijn eigen tool

hebben ter ondersteuning, waarmee mogelijk meerdere project management tools ingezet

worden. Analyse kan via een eigen gemaakte rapportege of via een vaste methode als UML

gebeuren. Binnen niveau twee is het mogelijk dat er projecten gestart zijn zonder gedegen

onderbouwing, goedkeuring of koppeling met organisatorische doelen. Dit zijn echter

uitzonderingen i.p.v. regel.

3. Derde niveau - Defined

Niveau drie kenmerkt zich door het gebruik van vaste methodes voor projecten, standaard

processen voor de governance, vaste communicatie wijzen en objectieve criteria. Er wordt

gebruikt met dezelfde ondersteunende applicaties die niet noodzakelijkerwijs gekoppelde zijn.

Per project is de Resourcing op dezelfde wijze geregeld, maar niet standaard over projecten

heen. Het proces is proactief. Het is mogelijk om CPM tools in te zetten en om het proces, de

standaarden en de beste werkwijze af te dwingen. Projecten zijn gekoppeld aan doelen, schuiven

met projecten is mogelijk maar kost veel werk in de berekening.

4. Vierde niveau – Quantitatively Managed

Alles is voor de complete organisatie in processen beschreven, voor zowel het gebruik, de rollen,

de criteria als de rapportages. Er wordt gebruik gemaakt van een CPM applicatie, voor de

diverse onderdelen zijn SPOT’s , maar deze zijn niet noodzakelijk onderling verbonden.

Resourcing gebeurt over alle projecten heen en optimalisatie gebeurt over het geheel. Portfolio

Management is goed ingericht en ook mogelijk met scenario’s voor alle varianten met een brede

impact over alle programma's.

5. Vijfde niveau - Optimizing

Alle processen zijn gekoppeld en de informatie is identiek voor alle ideeën, programma's en

projecten. Alle informatie wordt vanuit de diverse SPOT’s (Single Point Of Truth) opgebouwd

en vertrouwd. Dit kan betekenen dat er één HR-systeem wordt gebruikt dat voeding geeft aan de

PPM applicatie voor het inzetten van alle resources. Deze PPM applicatie is weer gekoppeld aan

een financieel pakket waar de facturen worden betaald voor de externe personen die ingehuurd

zijn op basis van hun werkelijk gemaakte uren. Het proces wordt op periodieke basis

geanalyseerd en aangescherpt indien nodig. Het vijfde niveau kenmerkt zich door het zich

Pagina {34}

continu verbeteren van de huidige werkwijze door op basis van gemeten processen te

optimaliseren.

F. Organisatie ICT Bij het beschrijven van de verschillende processen, waarbij deze in detail worden uitgewerkt,

worden ook de diverse benodigde rollen voor de betreffende processen beschreven. Aangezien

er niet een duidelijke standaard is waar elke ICT organisatie op gemodelleerd is, blijkt in de

praktijk dat elke (ICT) organisatie anders ingericht is. De meest gerenommeerde poging tot

algemene functiebeschrijvingen is uitgevoerd door de NGI met het rapport “Taken, Functies,

Rollen en Competenties in de Informatievoorziening" (WFBI, 2001).

In deze paragraaf zal een voorbeeld beschreven worden van de inrichting van een willekeurige

ICT organisatie. Om toch een basis te hebben voor de rollen die bij een proces invloed uit kunnen

oefenen of beslissingen kunnen nemen. Hierbij zijn uiteraard vele varianten mogelijk die in elke

organisatie een eigen match krijgt. Het is aan de lezer om deze match zelf te maken.

Verder spelen de rollen ook een onderdeel in de uiteindelijk te maken business case die ten

grondslag ligt aan het bereiken van niveau 3 van CPM volwassenheid. De rollen, of functies, die

betrokken zijn bij overlegstructuren zijn onderdeel van de operationele kosten van een

organisatie. De business case in dit boek heeft als mogelijke besparing het sneller en efficienter

nemen van beslissingen op basis van verbeterde informatie. Wanneer de overlegstructuren

gewijzigd worden in een vermindering van doorlooptijd of frequentie zal dit positief reflecteren

op de invoering van tools ter ondersteuning van het Corporate Portfolio Management.

Om een beter totaal beeld te krijgen van de rollen waar de CPM methode gebruik van maakt zal

in deze paragraaf niet alleen een voorbeeld worden gegeven van een totale organisatie, maar

ook van de ICT organisatie die daarbinnen opereert. Daarnaast zal de communicatie, de

interactie en de governance van en naar de ICT organisatie worden beschreven.

{voorbeeld}

a) Bedrijfsorganisatie

Het voorbeeld betreft een bedrijf tot ongeveer 100 FTE personeel voor de ICT. Deze

ondersteunen de gebruikersorganisatie, waarbij deze de grootte kan hebben van 1000 FTE. Het

is hierbij niet noodzakelijk het organogram van de totale organisatie weer te geven, echter zijn

er vanuit de gebruikersorganisatie wel enkele rollen erkend die nodig zijn voor het correct

uitvoeren van CPM. Daarom is ook in Figuur 6 Organogram een organogram opgenomen waarbij

de rollen zijn opgenomen die nodig zijn.

Pagina {35}

Figuur 6 Organogram

Binnen deze figuur is de ICT afdeling een aparte business unit en niet ondersteunend binnen de

staf voor alle primaire business units.

Het bestuur is samengesteld vanuit verschillende disciplines en verschillende

aandachtsgebieden. Ongeacht hoeveel mensen hierin betrokken zijn, onderscheiden we de

volgende functies:

CEO – De Chief Executive Officer, ook wel de algemeen directeur

CFO – De Chief Financial Officer, de contoler of hoogste financiële man

CIO – De Chief Information Officer, de manager van de ICT afdeling

Afhankelijk van de huidige economie valt de CIO onder of wordt deze naast de CFO geplaatst

binnen een organisatie.

Verder zijn de volgende functies van belang binnen een gebruikersorganisatie:

Hoofd divisie – de algemene manager verantwoordelijk voor een totale business unit. In

de figuur is het Hoofd Productie opgenomen.

Informatie Manager – de persoon functioneel verantwoordelijk voor de vertaling van de

business gedreven wensen en eisen richting de ICT afdeling.

Afdelingshoofd – de persoon binnen een business unit, verantwoordelijk voor een

onderdeel binnen deze unit (hier een afdeling).

Wederom is door een continue slingerbeweging de informatie manager of gesitueerd binnen de

business unit of binnen een aparte afdeling bij de ICT organogram. De figuur geeft aan dat de

aanbevolen plaats binnen een organisatie rapporterend is aan een business unit manager.

Pagina {36}

Voor de afdeling Marketing, Logistiek en mogelijke andere afdelingen, gelden uiteraard dezelfde

functies. Hierdoor komt in het voorbeeld het totaal aantal informatie managers en business unit

managers op vier.

b) ICT organisatie

Voor het uitwerken van de business unit ICT is een voorbeeld van een ICT organisatie

weergegeven in Figuur 7 ICT organogram.

Figuur 7 ICT organogram

Het organogram van een ICT organisatie is sterk afhankelijk van de grootte van de organisatie en

daarbij de verhouding lijn v.s. project organisatie deelname. Vaak is bij een grote organisatie de

ICT organisatie ingedeeld conform de business units of afdelingen die aan de gebruikerskant

ook gehanteerd wordt.

(1) Staf

Onderdelen van de staf ter ondersteuning van de ICT afdeling zijn mogelijk:

Bedrijfsbureau; De controleurs van de gemaakte uren, c.q. gemaakte kosten.

PMO; Het Project Management Office is verantwoordelijk voor het vergaren van

informatie vanuit de projecten t.b.v. directie en/of opdrachtgevers. Daarnaast is het vaak

onderdeel van de project ondersteuning voor het opstellen en afdwingen van project

standaards, zoals het gebruik van templates, methoden en tools. Dit kan ook

onderverdeeld worden in een PSO, de Project Service Office. De PMO wordt hierna in

een aparte paragraaf nader beschreven.

Ontwikkeling support; De specifieke helpdesk voor de afdeling ontwikkeling.

Risk & Compliancy; Personen die zich bezig houden met het opstellen en controleren

van gemaakte afspraken conform de gebruikte frameworks.

Security; Aangezien beveiliging een vakgebied is dat project en lijn overstijgend is,

wordt de security afdeling vaak als staf bijgezet in de ICT. Tevens zijn er medewerkers

van de beveiliging ingezet in de projecten ter borgen van deze beveiliging.

Pagina {37}

Strategy & Enterprise Architecture; Deze mensen houden zich voornamelijk bezig met

te gewenste toekomstige situatie van het ICT domein. Dit varieert van techniek,

platformen gebruikte kanalen en de gewenste architectuur daarbij. Architectuur wordt

vaak onderverdeeld in functies als applicatie, infrastructuur en data architecten. Vaak

worden deze ook in de projecten geplaatst om de uitgezette lijnen op enterprise niveau

te borgen in applicaties of services vanuit de door projecten op te leveren deliverables.

Kwaliteit Management; de functies behorende bij het opstellen en afdwingen van

kwaliteitsstandaarden. Vaak zijn deze ook ingezet in projecten voor de bewaking en

controle.

(2) PMO

Het is verstandig specifiek het PMO uit de lijst te lichten en in meer detail te bespreken. Het

Project Management Organisatie is verantwoordelijk voor de professionele ondersteuning van

het programma en of de diverse projecten. Dit betreft de onderstaande taken:

Business case; verzamelen en onderhouden benodigde informatie over de Business

case, waaronder de voortgang van de batenrealisatie. Tevens biedt het PMO

ondersteuning bij het periodiek actualiseren van de Business case.

Planning en beheersing; Inrichten van de benodigde procedures en infrastructuur van

het programma. Ondersteuning bij het ontwikkelen, de implementatie en de planning

van de beheersingsactiviteiten. Het verzamelen registreren distribueren van de

informatie nodig voor de aansturing van het programma. Stelt de planning op, houdt

deze actueel en bewaakt de voortgang.

Kwaliteitsmanagement; PMO stelt het kwaliteitsplan op ten behoeve van de

programmamanager en organiseert en bewaakt de uitvoering van reviews en audits. Is

verantwoordelijk voor het onderhouden van het issuelogboek en de monitoring van de

opvolging van de issues.

Risico management; PMO brengt de risico's in kaart ten behoeve van de

programmamanager of projectleider. Organiseert en bewaakt de riskmanagement

activiteiten en is verantwoordelijk voor het onderhouden van de risklog en de

monitoring van de maatregelen.

Financiële administratie; Registreren van financiële informatie, wijzigingsbeheer en uren

registratie en bewaking van het budget.

In de verschillende organisaties is de PMO op verschillende posities opgehangen in het

organogram. Wanneer de PMO een meer uitvoerend karakter heeft en een organisatie niet een

centraal aangestuurde methode ondersteunt, zal het PMO lager in het organogram geplaatst zijn.

Hoe meer generiek ondersteunend en organisatie breed het PMO opereert, hoe hoger in de hark

zij terecht komt.

(3) Service Management

Hieronder vallen alle werkzaamheden die te maken hebben met de 1e lijns helpdesk en incident

management. Alle issues worden hier aangemeld. Verzoeken tot wijzigingen voor functionele

zaken worden niet altijd via de helpdesk ingediend, maar de operationele wel. Gedacht moet

Pagina {38}

worden aan het aanvragen van een laptop of het aanmaken van een nieuwe gebruiker. Tevens

wordt in de meer volwassene organisaties gebruik gemaakt van services, een services catalogus

en worden deze services ook (pro)actief in de productieomgeving in de gaten gehouden door

exploitatie. Daarbij komt ook het vastleggen, in stand houden en acteren op SLA’s. Functies die

hierbij van belang zijn voor het CPM proces zijn ook de service managers. Deze personen zijn de

tegenhangers van de Informatie Managers aan de zijde van de business.

(4) Exploitatie

Alle functies behorende bij het operationele werk ter ondersteuning en draaiende te houden van

alle applicaties, het netwerk en/of de services. Database beheer (o.a. tuning en backups), pro

actief netwerk monitoring, file server monitoring en applicatie performance management.

Vaak is deze afdeling onderdeel van het 2e lijns helpdesk.

(5) Ontwikkeling

Alle functies gekoppeld aan het creëren, wijzigen of verwijderen van functionaliteiten van

(deel)applicaties of services. Binnen de weergegeven organogram worden twee groepen

onderscheiden:

Software ontwikkeling; De werkvloer in uitvoering van functionele wijzigingen. Hier is

een heel scala aan mogelijkheden, variërend van testers, ontwikkelaars, analisten en

bouwers. Deze functies komen zowel in de lijn als in de project variant voor. Bij kleine

bedrijven zijn de personen vaak zowel in de lijn als in project werkzaam. Hierbij is de lijn

verantwoordelijk voor het uitvoeren van dagelijkse werkzaamheden t.b.v. ondersteuning

in de tweedelijns service management.

Project Management; De personen verantwoordelijk voor het uitvoeren van

(deel)projecten, onderverdeeld in project leiders, project managers en program

managers. Teamleiders worden vaak binnen de software ontwikkeling geplaatst en niet

binnen deze afdeling.

c) Programma organisatie

Om het geheel te complementeren is ook een overzicht weergegeven voor het opzetten van een

programma (Figuur 10 Programma Organisatie voorbeeld) organisatie. In deze figuur wordt een

compleet beeld geschetst van een vraag en aanbod situatie.

Het opzetten van een programma organisatie is niet alleen noodzakelijk voor het goed uit

kunnen voeren van de diverse projecten die er onder vallen. Het is ook de basis voor de

acceptatie van de voorgestelde verandering binnen de organisatie en de governance die nodig

is voor het doorvoeren van deze verandering. Een opdrachtgever ziet duidelijk het nut en

noodzaak voor een project, maar de rest van zijn/haar organisatie wellicht een stuk minder. In

het belang voor het Corporate Portfolio Management is voornamelijk deze laatste twee

aspecten die de aandacht behoeven. Het krijgen van een groot draagvlak voor de verandering is

een van de grootste succesfactoren van een programma. Daarbij is de governance een van de

belangrijkste hulpmiddelen om dit draagvlak te krijgen. Governance levert inspraak en

betrokkenheid vanuit de gebruikersorganisatie die, mits goed ingeregeld, kan leiden tot grote

commitment naar het einddoel.

Pagina {39}

Figuur 8 MSP programma organisatie

De MSP methode wordt uitgelegd in het hoofdstuk Fout! Verwijzingsbron niet gevonden. bij de

paragraaf Fout! Verwijzingsbron niet gevonden.. Vanuit MSP wordt een generieke verhouding

weergegeven in Figuur 8 MSP programma organisatie. Hierbij is de opzet en organisatie van het

programma gescheiden van de implementatie van de verandering. Aan de linkerzijde is de

Programme Manager verantwoordelijk voor het uitvoeren van de projecten en de Business

Change Manager voor de uitrol en acceptatie. De programma manager moet dus afstemmen

met de BCM over planning, eindresultaat, kwaliteit, etc. als gelijke. De opdrachtgever stuurt

beide personen aan.

Wanneer het programma over meerdere afdelingen (business units) loopt, waarbij de planning

en afstemming van groot belang is, ziet men in de praktijk deze opzet veranderen. De Business

Change Manager wordt per business unit aangesteld en heeft twee mogelijk conflicterende

opdrachtgevers. Deze spanning zal goed gemanaged moeten worden door de programma

manager en zeker niet weggenomen worden. Deze spanning zorgt juist voor het feit dat een

afdeling mee praat over het einddoel en hoe dit bereikt wordt. Tevens zorgt het ervoor dat een

programma manager binnen een afdeling goedkeuring, commitment en medewerking krijgt.

Alle belangen worden hierbij gedekt. Dit geldt overigens niet alleen voor de business units

waar de verandering noodzakelijk is, maar ook voor de afdelingen die het uiteindelijke beheer

moeten gaan uitvoeren. Het is zaak ook deze afdelingen zo vroeg mogelijk te betrekken bij het

opzetten van het programma voor exact dezelfde redenen als het betrekken van de business

units.

Pagina {40}

Figuur 9 Programma Streams

Bij het opzetten van de programma organisatie zijn grofweg twee varianten mogelijk, namelijk

een indeling via de deliverables of een indeling conform de betrokkenen. De indeling via

deliverables (of tegenwoordig vaak streams genoemd) zullen voor de oplevering van hun

doelen de juiste organisatieonderdelen moeten betrekken om dit te kunnen volbrengen. Voor de

indeling via de betrokken business units zal gekeken moeten worden welke deliverables voor

elke business unit opgeleverd moeten worden. Welke variant gekozen wordt, er zal altijd een

nadeel aan kleven, namelijk de coördinatie tussen deze streams of business units.

Om het geheel te complementeren is ook een overzicht weergegeven voor het opzetten van een

programma (Figuur 10 Programma Organisatie voorbeeld) organisatie. In deze figuur wordt een

compleet beeld geschetst van een vraag en aanbod situatie. De nu volgende beschrijving gaat van

rechts naar links.

De vraag (of demand) gedeelte is een of meerdere business units die zelf in een hiërarchische

lijn zijn verbonden. Deze demand organisatie heeft lijnmanagers en resources die hieraan

rapporteren. De Demand organisatie levert zowel personen in de stuurgroep voor het

aansturen van de eisen en wensen, alsmede de controle op kosten, scope, deliverables en de

kwaliteit. Verder levert ze ook capaciteit vanuit de lijn in het opstellen van de requirements, het

stellen van een functioneel ontwerp en, afhankelijk van de positionering van de informatie of

business analisten, aanvulling in technisch of data ontwerp. Uiteindelijk levert ze ook capaciteit

voor het testen van de uiteindelijk op te leveren (deel) service. Dit laatste aan het einde van de

ontwikkelcyclus, GAT de Gebruikers Acceptatie Test, of afhankelijk van de gekozen

ontwikkelmethode de acceptatie testen gedurende oplever cyclussen.

De demand organisatie is een weerspiegeling van de project organisatie. Deze hoeft in aantal

FTE’s niet gelijk te lopen, maar wel vaak zoveel mogelijk in rollen. Zoals weergegeven komen

deze rollen neer op:

Testing

Communicatie

Contract Management

Deze vallen in tegenstelling tot een programma organisatie onder een portfolio manager (of

zoals eerder aangegeven een Business Change Manager). De programma manager is

eindverantwoordelijk voor de oplevering van het project richting de business. De portfolio

manager van de business is voornamelijk bezig met verwachtingsmanagement. Tevens is zij een

belangrijke spil in het accepteren van kosten, scope, deliverables en deadlines.

Pagina {41}

Figuur 10 Programma Organisatie voorbeeld

De daadwerkelijke uitvoer van het project, dus het testen, opstellen van specificaties, kwaliteit

programma’s, gebeurt in de vorm van (deel)projecten die elk bezig zijn een deel van de

deliverables op te leveren. In de figuur zijn dit vijf projecten die onderhanden zijn. Het is

overigens niet zo dat de demand en supply gescheiden opereren binnen het programma. De

scheiding is voornamelijk gekozen door duidelijk te maken hoe de verschillende belangen en

organisaties hier in zitten.

Vanuit de ICT wordt het programma opgezet op dezelfde wijze als de Demand zijde. Ook hier

komen veel van de resources uit de lijn van de ICT omgeving. Deze functies zijn dagelijks bezig

met het huidige ICT landschap en zijn als geen ander in staat om impact van project oplevering

richting de lijn te bepalen en te bewaken. Kleinere organisaties zullen de spanning kennen van

capaciteit die gedeeld wordt tussen lijn en project taken. Hierbij spelen prioriteiten vanuit de

lijn, te denken valt aan issues vanuit de gebruikersorganisatie, t.o.v. projecten een grote rol.

Tevens is bij oplevering van nieuwe services een spanningsveld richting het embedden van

deze service in de lijnorganisatie. Hoe groter het project of de service hoe groter dit

spanningsveld. Onderdeel van het project is dan ook het zorgen voor een adequate overdracht.

2. Rollen

De rollen die onderdeel uit maken van de processen binnen het CPM proces zullen hieronder

worden benoemd en uitgewerkt. Per proces zal bij de beschrijving van het CPM proces de

gewenste rollen worden genoemd.

Opdrachtgever; De opdrachtgever is de persoon die vanuit bedrijfsvoering de noodzaak voelt om

een (grote) verandering in haar organisatie door te voeren. Hiervoor heeft zij budget

aangevraagd en is ze verantwoordelijk voor het vaststellen en verkrijgen van de door haar

gewenste verandering. Zij is vaak de manager van de groep eindklanten en in het geval van een

programma onderdeel van het bestuur. Deze persoon is in staat om zelfstandig beslissingen

door te voeren die de output van het project kunnen veranderen. Door de uitvoer te veranderen

Pagina {42}

kunnen ook de daarbij behorende restricties van budget, kwaliteit of tijd veranderen. Zij is

uiteindelijk de persoon die (gedelegeerd) de eindsituatie goedkeurt en het programma decharge

geeft.

Programma manager; De programma manager is opdracht uitvoerder en eindverantwoordelijke

voor de oplevering van de gewenste verandering. De programma manager stuurt overkoepelend

de diverse projecten aan en zorgt voor de afstemming binnen en buiten het programma. Hierbij

specifiek sturend op:

1. Stakeholder management; het afstemmen met de diverse belanghebbende en

accepterende partijen.

2. Project management; het sturen en afstemmen binnen en tussen de diverse lopende

projecten.

De programma manager is verantwoordelijk voor een werkende governance, voor

verantwoording van het budget en de oplevering richting de opdrachtgever. Deze wordt vaak

gedelegeerd naar de projectleider.

Project leider; De projectleider, of project manager, is eindverantwoordelijke voor het doel van

het project binnen de daarvoor geldende restricties van budget, tijd en resources. De

projectleider levert een planning, de daarbij behorende huidige stand van zaken en beheert de

restricties.

Figuur 11 Project Manager functie overzicht

Project teamlid; Teamleden produceren output of deliverables voor het project. Ze draaien ook

mee in het leveren van informatie over voortgang en planning. Ze geven zelf aan hoeveel werk

een taak kost en zullen deze vervolgens uitvoeren wanneer ze in planningen worden

opgenomen. Hierin geldt een haal en breng plicht, omdat de inhoudelijk kennis van het traject bij

de teamleden ligt en niet zo zeer bij de projectleider. De daadwerkelijk inzet wordt proces matig

bepaald door de HR manager van de desbetreffende afdeling.

Pagina {43}

Sponsor; De sponsor is onderdeel van het management en is de persoon die als tussenpersoon

tussen projectleider en management fungeert. Deze persoon lift mee op de resultaten van het

project, haalt daar voordeel uit, en heeft een politieke stem in het geheel.

Eindklant; De eindklant is de persoon of groep van personen die de uiteindelijke oplevering van

het project accepteert. Hun behoeftes en eisen/wensen zijn de bron van het bestaansrecht van

het project. De eindklant zit met teamleden in overleg over de oplevering.

PMO; De Project Management Office is/zijn personen die verantwoordelijk zijn voor het

verkrijgen van informatie, het bundelen en leveren van deze informatie richting MT/Raad van

Bestuur. Tevens is het PMO verantwoordelijk om de projecten en/of projectleiders te

ondersteunen in methodes, technieken of tools. Afhankelijk van het volwassenheidsniveau van

de organisatie is deze rol een secretaresse of een zware projectleiders functie.

Portfolio Manager; De rol van portfolio manager kan op diverse posities binnen een organisatie

bevinden. Er is namelijk niet 1 portfolio manager die het geheel kan en gaat overzien. Zo kan de

rol van portfolio manager in een business unit gestalte krijgen als de persoon die het geheel aan

projecten en wijzigingen beheert die richting de ICT service organisatie wordt uitbesteed. Dit

kan zowel vanuit de startende ideeën fase, de uitvoerende project fase als de services die in

beheer zijn fase zijn. Wanneer binnen een beheer afdeling een rol van portfolio manager wordt

gecreëerd, is deze verantwoordelijk voor het managen van alle wijzigingen die een programma

door wil voeren en zal dus in elke fase van een service (idee, uitvoer en productie) de belangen

van de beheer afdeling moeten behartigen. Het wordt daardoor een liaison functie van

programma naar beheerafdeling en terug. Als de Portfolio Manager binnen de uitvoer van

projecten een rol krijgt, zal deze zich eerder in een PMO afdeling handhaven. Dit omdat de

primaire belangen van een Programma Manager of Projectleider het uitvoeren van een opdracht

binnen de aangegeven grenzen is. De zinvolheid van een project is niet een primaire taak van

een Projectleider, wel de haalbaarheid ervan. Afhankelijk van de grootte en volwassenheid van

een organisatie is deze rol een zelfstandige functie.

HR managers; Dit zijn managers die resources leveren voor een project in de vorm van

teamleden. Deze kunnen uit zowel vanuit de eindgebruikers organisatie komen, de ICT

(ontwikkelaars of operationeel management) als bijvoorbeeld functioneel beheer.

3. Governance

Een aparte paragraaf is hier ingelast voor de governance van goedkeuring. De governance

betreft het geheel aan processen dat ingericht is voor het sturen van programma’s en processen.

Het begrip stamt reeds uit de tijd van de oude Grieken, aangezien het Plato was die het originele

begrip, sturen, metaforisch gebruikte in zijn werk. In het Nederlands is dit nu vertaald als

"behoorlijk bestuur". Binnen de totale organisatie betreft het de besturing van de onderneming,

echter word het begrip governance binnen dit boek gebruikt om de (be)sturing van en rond de

projecten en programma’s te beschrijven. Deze is gekoppeld aan de communicatie tussen de

groepen en binnen de diverse projectgroepen.

Het is de transparantie in deze processen die de governance binnen een organisatie bepaalt. Als

in een organisatie gevraagd wordt "welke afdeling of functie de beslissingen neemt omtrent het

al dan niet uitvoeren van de juiste projecten voor de ondersteuning van de strategische

doeleinden van een organisatie? " komen vaak diverse antwoorden. Afhankelijk wie je dit vraagt,

Pagina {44}

kan het antwoord de business zijn, die ene opdrachtgever, het PMO, de Programma Manager of

elk van de te identificeren beheersorganisaties. Hierbij zijn ook de criteria op basis waarvan een

beslissing genomen wordt niet duidelijk. Zo kan het gebeuren dat wijzigingen door een IT

afdeling worden afgewezen met de redenering dat dit indruist tegen het beleid van de

organisatie. Terwijl de rest van de afdelingen, die in een eerder stadium tot de conclusie

kwamen dat deze wijziging wel doorgevoerd moet worden, vindt dat zij hun mond dienen te

houden en moeten uitvoeren wat de afdelingen zelf in hun wijsheid besloten hebben.

Figuur 12 Governance

De governance heeft twee dimensies binnen een projectorganisatie, namelijk een horizontaal

en verticaal proces. De vraag wie nu een idee goedkeurt, behoort in het horizontale proces.

Binnen de CPM methode is deze governance volledig ingebouwd in de processen die opvolgend

bepalen welke ideeën uiteindelijk uitgewerkt worden tot een service. In deze paragraaf wordt

alleen de verticale governance nog even apart belicht. Dit omdat binnen de meeste project

management methodes deze vorm van governance onderdeel is van de in te richten project

structuur. De ondersteuning van deze structuur moet wel vormgegeven worden binnen de CPM

methode.

Binnen het eerder geschetste voorbeeld van programma organisatie structuur (zie Figuur 10

Programma Organisatie voorbeeld), is veel communicatie noodzakelijk voor het afstemmen van

activiteiten, deliverables, kosten en deadlines. Deze communicatielijn loopt van projectgroep,

naar stuurgroep en uiteindelijk naar strategisch overleg. De mogelijke soorten overleg zijn:

Projectgroep; Binnen elk project worden personen ingezet voor het daadwerkelijke uitvoeren

van een project. Dit wordt geleid door de projectleider of projectmanager die de

eindverantwoordelijke is binnen het project m.b.t. de oplevering van de deliverables, de kosten

en de daarbij behorende deadlines. Afstemming moet dus plaatsvinden tussen teamleden over

hun verantwoordelijkheid ten opzichte van de deliverables, de tijd die daarvoor gegeven wordt

en de afhankelijkheden tussen het project en de buitenwereld, maar ook voor de taken binnen

het project. Project overleg; Doel van dit overleg is de coördinatie verzorgen voor het behalen

van een te voren bepaalde milestone van het (deel)project. Leden hiervan zijn de

daadwerkelijke teamleden (testers, ontwikkelaars, beheerders en de projectleider is voorzitter).

Frequentie is wekelijks.

Projectstuurgroep; De projectgroep wordt beoordeeld door de projectstuurgroep die alle,

binnen de door het project opstelde documentatie vastgelegde werkzaamheden, beoordeelt en

Pagina {45}

beslissingen maakt binnen de voor het project vrijgegeven ruimte. Deze ruimte is aangevraagd

door de programmastuurgroep en goedgekeurd door de strategische stuurgroep. Binnen de

projectstuurgroep is het doel dus consensus te verkrijgen op de voor het project gestelde scope,

doel en binnen de daarvoor gestelde middelen. Hierin valt zeker het opnemen van de

deliverables binnen de staande organisatie, het in beheer nemen. Projectstuurgroep overleg;

Doel van dit overleg is voortgang bewaking, keuzes maken binnen de toegestane grenzen en

afstemming tussen de diverse betrokken partijen. Leden hiervan zijn vertegenwoordigers van de

betrokken afdelingen, zoals teammanagers van gebruikersgroepen en leveranciers van

teamleden. Voorzitter kan project manager zijn. Frequentie is afhankelijk van de fase waarin het

project zich bevindt.

Programmastuurgroep; Het programma beslist over zaken die projectoverstijgend zijn. Hier

kunnen bottlenecks gesignaleerd worden en op een programma niveau worden opgelost. Bij

grote programma’s is het kostenefficiënt om op dit niveau uniforme processen en activiteiten te

coördineren en uit te voeren. Denk bijvoorbeeld aan testperiodes waarbij generieke

testdocumenten eenmaal gemaakt te hoeven worden en vervolgens in de detail uitgewerkt

moeten worden in de diverse projecten. Dit geldt zeker wanneer de (lijn)organisatie niet

centraal zaken op een voldoende volwassenhiedsniveau heeft opgesteld. Op programma niveau

worden ook generieke afspraken gemaakt over standaard deliverables, uitspraken gedaan die

voor alle projecten gelden en prioriteiten binnen het programma scherp uitgesproken.

Knelpunten op bijvoorbeeld resources of deadlines waarbij het ene project het andere project

(binnen hetzelfde programma) in competitie zijn, worden op dit niveau opgelost. Alle

documenten uit de projecten (of projectstuurgroepen) worden in dit gremium gepland,

besproken en goedgekeurd. Het programma stuurgroep overleg; Hierin worden beslissingen

genomen over het totale pallet van opgeleverde zaken, kosten in de planning v.s. kosten

gemaakt, EVA, deadlines. Hier draait de PMO mee voor het opleveren van deze zaken, waarbij

de verantwoordelijkheid van de projecthuishouding blijft liggen bij de projectmanager. De PMO

levert informatie, waarbij de inhoud zo goed is als de projecten deze aanleveren. Leden hiervan

zijn de opdrachtgever, de programma manager en alle directeuren van de uiteindelijk betrokken

afdelingen (zowel leverancier als acceptant). Frequentie is maandelijks.

Strategische stuurgroep; De strategische stuurgroep is de groep die uiteindelijk budget

goedkeuringen kan geven. De groep geeft goedkeuring over de start van programma's en

projecten. Het geeft uiteindelijk decharge wanneer het programma opgeleverd heeft wat het van

te voren heeft afgesproken. De strategische stuurgroep heeft geen gedetailleerde kennis van de

onderliggende technische systemen en moet dus gevoed worden door de achterban die

betrokken moet worden in de overleggen op tactisch niveau. Escallaties op dit niveau worden,

mits politiek goed gevoed, bindend gecommuniceerd naar de betrokkenen. Strategisch overleg;

Alle vergaderingen die belegd worden voor de sturing van een project op mijlpalen, waarbij

zowel de uitvoerende als de vragen partij onderdeel uit maken. Leden hiervan zijn directieleden.

Frequentie is kwartaal gebonden.

Hier dient ten eerste opgemerkt te worden dat hoe hoger de betrokkenen van het overleg in de

organisatiestructuur zitten, hoe minder frequent deze groep bij elkaar komt. De datums van

deze vergaderingen en de tussenliggende periodes zorgen voor een heel eigen dynamiek binnen

de diverse programma’s en projecten. Leden van elk van deze stuurgroepen zijn in ieder geval

de leiders/managers van deze groep (afhankelijk van de grootte van een bedrijf zullen in de

Pagina {46}

verticale hiërarchie genoeg managers zijn om aan te schuiven) en de opdrachtgever. Verder zijn

er vaak specifieke steakholders, leveranciers van resources of leiders van mogelijke

deelprojecten die deelnemen aan de verschillende groepen.

Ten tweede betekent dit dat ergens in de lijn "naar boven" minder op de inhoud en meer op de

rapportages wordt gestuurd. Het moet niet onderschat worden hoe snel dit proces plaatsvindt.

Deze rapportages zijn vaak gebaseerd op cijfers en niet op inhoudelijke kwalificaties. Een

betrokken leverancier zal dus ook intern moeten waarborgen dat de juiste informatie wordt

doorgegeven naar vertegenwoordigers in de desbetreffende overlegstructuren.

Figuur 13 Governance in een tijdbalk

Bij een zeer strikt nageleefde governance zijn niet alleen maar voordelen te behalen. In de

praktijk ontstaat vaak een onwenselijke situatie van het vasthouden van bemensing voor

projecten door het slechte aansluiten van de governance ten opzichte van de looptijd van

projecten. Voor de afronding van een fase zou goedkeuring moeten plaatsvinden vanuit een

hoger gremium om voortgang te maken. Afhankelijk van de grootte van een organisatie zijn dit

meerdere groepen en personen die goedkeuring moeten geven voor bijvoorbeeld het opstarten

van een project, bij goedkeuring van het vooronderzoek. Zoals gezegd is de frequentie van

vergaderen omgekeerd evenredig met de hoogte van de hiërarchie binnen zo’n organisatie, wat

betekent dat voor het verkrijgen van budgetaire goedkeuring vaak een lang, in tijd en proces,

traject afgelegd moet worden.

{voorbeeld} Het in Figuur 13 Governance in een tijdbalk weergegeven vergaderfrequentie overzicht,

levert al direct opvallende zaken op. Namelijk dat er voor een project ook gepland moet worden

rondom het programma stuurgroep en het strategische stuurgroep overleg. In dit voorbeeld is

het project stuurgroep overleg wekelijks, het programma stuurgroep overleg maandelijks en het

strategische stuurgroep overleg eens per kwartaal. Om een document goedgekeurd te krijgen in

het programma stuurgroep overleg zal het een review ronde moeten doorlopen bij de

belangrijkste steakholders die in het overleg mogelijk hun commentaar hebben. Dit betekent dat

minimaal een week (afhankelijk van de afspraken) het document in de ronde gaat meedraaien,

waarbij er ook verwerking op de commentaren moet ingecalculeerd worden. Deze extra ruimte

is voor de goedkeuring, meestal van het budget, in het strategische stuurgroep overleg twee

maal zo groot. Namelijk eerst de goedkeuring van de programma stuurgroep en daarna in de

strategische stuurgroep. Bij tijdsnood gaan in dit traject vaak creatieve mailwisselingen

ontstaan.

Aangezien het de stuurgroepen zijn die toestemming geven op fasen overgangen, zullen de

meeste projecten ook hier op gaan focussen. Maar zoals net aangegeven bestaat er een

Pagina {47}

overbruggingsperiode bij het afronden/schrijven van een document en de daadwerkelijke

goedkeuring. Het resultaat van deze dynamiek kan zijn dat men soms maar doorgaat “vanweg

pragmatische redenen”. Hierdoor krijgen de personen die de goedkeuring moeten geven op de

verschillende niveau’s soms het idee dat hun mening uiteindelijk niet er toe doet. Ongeacht hun

goedkeuring is het project aan het ‘doordenderen’.

Een andere mogelijkheid is het feit dat de datums waarop belangrijke projectdocumentatie,

zoals een planning of PID (zie hoofdstuk Fout! Verwijzingsbron niet gevonden. Fout!

Verwijzingsbron niet gevonden. op pagina Fout! Bladwijzer niet gedefinieerd. voor een

verklaring van de termen), als uitgangspunt wordt genomen i.p.v. de gewenste opleverdatum.

Het plannen van een fase einde wordt geplot op overleg datums en minder op het afronden van

de werkzaamheden. De deadline staat vast, hoe komen we tot dat punt? Deze deadlines

kunnen steeds meer gezien worden als adminstratieve datums waarop gestuurd wordt door

hoger hand. Wanneer een goedkeuring gegeven moet worden zal enkele weken daarvoor de

oplevering moeten plaatsvinden van het stuk wat goedgekeurd moet worden. Ongeacht het feit

dat het mogelijk voor een project niet wenselijk is om nu reeds een document op te leveren

omdat het nog niet af is. Documenten uit vooronderzoeken kunnen door gebrek aan tijd zaken

niet opgenomen hebben of met de mededeling dat deze in de realisatie fase toch nog uitgezocht

moeten worden. Hiervoor wordt dan een stelpost opgenomen, maar netjes is het niet.

Daarnaast is het in een organisatie waarbij geen algemene governance wordt gehanteerd vaak

ook niet de regel om en governance structuur van te voren op te stellen en te laten goedkeuren.

Zo kan elk programma een eigen governance opstellen, uitvoeren of veranderen naar eigen

goeddunken. Aangezien het opstellen en naleven een centrale activiteit is, zal dit altijd altijd

binnen een centrale PMO opgepakt moeten worden. Dit heeft van invloed op het algemene

volwassenheidsniveau van een project organisatie.

4. Communicatie

In de vorige paragraaf wordt algemeen gesproken over de governance van IT projecten. Een

belangrijk onderdeel van de governance is de communicatie over de besluitvorming. In elk

beschreven (deel)proces van de CPM methode wordt de communicatie over de genomen

besluiten meegenomen als onderdeel van de output. Soms zelfs explicitiet als deelproces (zie

proces 1. Vaststellen Visie & Strategie) en soms als onderdeel van de output van het deelproces.

De praktijk laat zien dat het opstellen van een communicatieplan zich zelden begeeft op het

terrein van goed en duidelijk informeren over uitermate belangrijke zaken als besluitvorming

binnen de verschillende processen die onderdeel zijn van het portfolio management. Los van het

feit dat veel gewerkt wordt met (excel)lijsten waarin de huidige stand van zaken wordt

beschreven m.b.t. een onderwerp, staat veel informatie in applicaties als helpdesk tools,

testregistratie tools of project management tools opgeslagen. Hierbij wordt ook de actuele

status verward met een overzicht van besluiten. Vaak liggen besluiten wel ten grondslag aan

deze actuele status, maar een lijst met prioriteiten geeft niet aan wie besloten heeft dat deze lijst

er zo uit ziet, wanneer dit gebeurd is en met welk mandaat dit is gebeurd. Vaak heeft niet

iedereen toegang tot eerder genoemde applicaties en het bijhouden van lijsten beperkt zich tot

de mensen in de CC van de e-mail.

Een van de in de praktijk vaak voorkomend probleem is het bijhouden van beslissingen die

genomen zijn of worden in vergaderingen. Deze kunnen in de vorm van afspraken zijn, maar ook

Pagina {48}

het beslissen om prioriteiten te herschikken. Hierbij gebeurt het ook dat beslissingen worden

genomen die totaal niet genomen kunnen worden door de aangesloten leden van deze

vergadering. Niet alleen omdat de leden mogelijk niet het juiste mandaat bezitten, maar ook

omdat de vergadering geen zeggenschap heeft over het te nemen besluit.

Aangezien niet iedereen in dezelfde vergaderingen aanwezig is, moeten sommige besluiten

teruggekoppeld worden aan de personen waar de beslissing van invloed is. De wijze waarop is

vaak mondeling, vaak via vergaderingen die opvolgend zijn door dezelfde personen, soms via

een bijgehouden besluitenlijst via de vergadernotulen en de e-mail of telefoon. Deze laatste

werkt natuurlijk het beste met slecht nieuws.

Standaard onderdeel van het communicatieplan is een periodieke update via de mail aan allen in

een project en geïnteresseerden daarbuiten. Hoog over wordt gemeld dat alles goed gaat en

waar men zo druk mee is. Wanneer een belangrijk project zijn akkoord krijgt om in productie

genomen te worden, of wanneer het dit niet krijgt, wordt ook via de mail verkondigd. Dit begint

vaak al snel een ad hoc karakter te krijgen.

Proces 7 is geheel gewijd aan het bijwerken van de status van het portfolio en het rapporteren

daarvan. Onderdeel is het verwerken van de beslissingen die genomen worden met betrekking

tot het portfolio. Dit moet niet verward worden met het feit dat communicatie, zoals hierboven

geschetst, meer omvat dan een rapport te draaien op de huidige feiten. Wanneer de CPM

methode ondersteund wordt door een Project & Portfolio Management applicatie is het mogelijk

om de beslissing van bijvoorbeeld het 6 maanden later starten van een project te verwerken met

de druk op een knop. Dit ontslaat niemand van het feit dat deze beslissing op een fatsoenlijke

manier gecommuniceerd moet worden naar alle betrokkenen. Daarnaast is het geen standaard

functionaliteit van dit soort applicaties om de genomen beslissingen te centraliseren voor

eventuele historisch gebruik.

5. Politiek

Een van de minst gedocumenteerde zaken die het meeste invloed op projecten en programma's

heeft, is de politiek die rondom (grote) projecten speelt. De belangen zijn vaak groot en soms

helemaal niet gedeeld tussen de verschillende partijen. Hierdoor is de dynamiek van een

programma ook voor de programmaleden bepalend of het een succes wordt of niet.

De CPM methode heeft organisatie psychologie niet opgenomen als onderdeel van de

(deel)processen. Wel poogt het via het expliciet beschrijven van processen, beslissingen en de

daarbij gehanteerde criteria zoveel mogelijk de objectieve kant van programma's te

benadrukken. Toch is het in vele gevallen niet mogelijk om slechts die informatie te laten zien

die nodig is om een beslissing te forceren. In de praktijk is het stopzetten van een project

bijvoorbeeld niet voor elk deelnemende stakeholder even gemakkelijk. Ook al spreken de

objectieve gegevens voor zich.

Dit geldt tevens voor het project voor het verbeteren van de CPM methode zelf, al dan niet door

het invoeren van een Project & Portfolio Management applicatie. Niet iedereen is gebaad bij de

inzage in de actuele status van alle projecten die betrokken zijn in een organisatie.

6. Interactie

Wanneer gesproken wordt over communicatie tussen ICT afdeling en de gebruikersorganisatie

betreft het uitwisseling van verschillende vormen van wensen/eisen voor ondersteuning. De ICT

Pagina {49}

is verantwoordelijk voor ondersteuning in elke laag en in elk proces van een organisatie. Het is

inmiddels niet meer weg te denken binnen een organisatie.

Wanneer in een dagelijkse basis de interactie beschreven wordt, zonder lopende projecten, kan

deze gezien worden in de gebieden change en run. Hierbij is de run de operationele

ondersteuning van de dagelijkse werkzaamheden van de lijnorganisatie. De change is het

doorvoering van wijzigingen die de lijnorganisatie kan verbeteren in haar werkzaamheden.

In de praktijk kan deze change interactie verdeeld worden in de drie volgende niveaus, conform

de indeling in strategisch, tactisch en operationeel:

1. Issues en verstoringen.

De communicatie tussen gebruikers bij het aanmelden van verstoringen is de helpdesk. Hierbij

wordt de informatie nodig voor het verhelpen van de verstoring genoteerd via de eerstelijns

ondersteuning. Afhankelijk van de gebruikte methode, bijvoorbeeld ITIL, worden processen in

gang gezet om deze verstoring te verhelpen.

2. Verzoeken tot wijzigingen.

Wanneer er geen sprake is van een verstoring, maar van verzoeken om functionele of

operationele wijzigingen wordt dit gestart via de helpdesk of via de Informatie Manager. Het

aanvragen van nieuwe hardware, aanmaken van nieuwe gebruikers, etc. (operationele

wijzigingen) zal via de helpdesk verlopen en het reguliere kanaal van ondersteuning

bewandelen.

Functionele wijzigingen of wijzigingen in de operatie die door de ICT gewijzigd moeten worden,

volgen een traject waarbij de Informatie Manager de coördinatie uitvoert. Zijn/haar evenknie is

de Service Manager die verantwoordelijk is voor de coördinatie vanuit de ICT afdeling. Beiden

zijn verantwoordelijk voor de verwachting richting de eindgebruiker.

3. Strategische ondersteuning.

Strategische ondersteuning betreft wijzigingen op grote schaal zoals het invoeren van nieuwe

applicaties of wijzigingen van nieuwe informatie kanalen. Zaken als deze worden ingebracht op

vergaderingen op strategisch niveau, ingezet door de business managers of directie niveau en

beantwoord door het ICT MT, vaak gesteund door de PMO of Project Manager. Vaak zijn er

eenvoudige richtlijen, waarbij bijvoorbeeld gekozen wordt om een change die meer kost dan

€40.000 bijvoorbeeld altijd een project is.

G. Project Management Vele project management boeken starten met even zovele definities van projecten. Om open

deuren zoveel mogelijk open te houden, zijn voor het doel van dit boek projecten samen te

vatten als:

Een project levert iets op en heeft dus voor alle betrokken projectleden een

gemeenschappelijk doel. Hierbij is de opdrachtgever verantwoordelijk voor het opstellen

van dit doel, met de daarbij behorende tijd, geld en kwaliteitsrestricties. De uitvoerende

organisatie is eindverantwoordelijk voor wat er opgeleverd wordt en de opdrachtgever

is wederom verantwoordelijk voor de goedkeuring daarvan.

Pagina {50}

Een project is een tijdelijke onderneming in zowel tijd als resources als budget; Een

project heeft een duidelijke kop en een staart. De begindatum is de datum waarop men

reeds voorbereidingen gaat plegen voor het project en moet niet verward worden met

de startdatum waarop het project goedkeuring krijgt om te starten. De einddatum is de

opleverdatum van het project, de datum waarop de deliverables klaar zijn. Vele

projecten hebben ook nog een nazorg fase, een fase waarin de tijdelijke bezetting

ondersteuning biedt omdat de projectmedewerkers de meeste kennis hebben van de

opgeleverde applicatie. Tevens is er ook vaak ruimte voor evaluatie, maar ook vaak niet.

Verder heeft een project beperkingen in de in te zetten mensen en de te gebruiken

budgetten. Voor een van te voren geplande hoeveelheid werk en geld zal het doel bereikt

moeten worden.

Een project heeft een aparte hiërarchie; De bezetting van mensen in het project levert

een tijdelijke en aparte hiërarchie op, waardoor het vaak gebeurt dat personen zowel

aan de projectleiding als aan hun lijnmanagers verantwoording moeten afleggen.

Een project heeft unieke eigenschappen; Alhoewel projecten vaak gemeenschappelijke

karakteristieken hebben, is aan elk project iets unieks. Zonder dit unieke gegeven,

zouden projecten geleid kunnen worden als een productiebedrijf. Hierbij zouden andere

methoden gehanteerd kunnen worden met een andere aansturing.

Een project maakt gebruik van een geplande wijze van taken coördineren; Dit wordt in

de volksmond ook wel projectmethode genoemd. De methode zorgt ervoor dat de

verschillende taken een samenhang vertonen, afhankelijkheden in beeld worden

gebracht en de daarbij behorende deliverables gekoppeld worden.

Een projectleider zal vele zaken moeten managen in een project. Communicatie is hierbij zeer

belangrijk. Dit geldt niet alleen voor interne projectcommuncatie, maar zeker ook externe

communicatie. Het is hier niet de bedoeling om een boek over projectmanagement te schrijven,

maar niet onbelangrijk en niet beschreven zijn:

communicatie

People skills

stakeholder management

Kwaliteitsplan

De reden waarom deze aspecten niet worden besproken is het feit dat ze a) niet van invloed zijn

op het Portfolio Management of b) niet ondersteund kunnen worden door tools.

In deze paragraaf volgt een tweedeling van planning en reporting. De planning heeft te maken

met de taken van een projectleider voorafgaand aan de start van een project. Alle zaken die

geregeld moeten worden voordat de eerste taak wordt ingezet, hebben in principe te maken met

inschattingen over tijd, doel, budget en kwaliteit van hetgeen een project moet opleveren. De

reporting heeft te maken met de zaken die een projectleider uitvoert en op basis waarvan zij

kan sturen gedurende het project. Hierbij zijn bovenstaande communicatie aspecten van cruciaal

belang voor het welslagen van een project, maar de onderbeschreven taken hebben te maken

met inzet van tools voor het uitvoeren van een project.

Pagina {51}

Deze tweedeling is ingezet met in het achterhoofd de mogelijkheid om zaken met tooling te

ondersteunen, echter is hierbij terdege rekening gehouden met het feit dat deze scheiding niet

zo klinisch te maken valt. Een project valt niet van de ene dag op de andere vanuit de planning

naar uitvoering. In principe zijn dit dus ook twee verschillende aspecten die beiden behoren tot

de activiteiten van een projectleider.

Alhoewel de ondersteuning met behulp van tooling als leidraad genomen is bij het beschrijven

van de taken van een projectleider, is de koppeling niet 1 op 1. Het is niet zo dat binnen de CPM

methode alle hier genoemde onderdelen of taken expliciet worden meegenomen in het

beschrijven van de procesvoering. Zo is het opstellen en bijhouden van een issuelog een

standaard voor veel projectmethodes. Deze wordt echter niet meegenomen als verplichte output

wanneer de acht processen van de CPM methode in detail worden uitgewerkt.

1. Planning

Voordat een project van start gaat is er een (of meerdere) fase waarin de projectleider reeds

voorbereidende werkzaamheden uitvoert. Deze kunnen al gelang de grootte en de scope van het

project gedurende een langere periode plaatsvinden en desgewenst ook een

haalbaarheidsstudie omvatten. Ook tijdens het uitvoeren van een project zal een projectleider

moeten plannen en herplannen naar mate de interne en externe factoren hun invloed op haar

ideale situatie zich laten gelden. Gedurende de (pre-)project fase houdt een projectleider zich

bezig qua planning met de volgende gebieden:

Proces; Het gehele proces voorafgaand aan en tijdens de uitvoer van een project zal bewaakt

moeten worden door de projectleider. Vanuit de standaard werkwijze van een organisatie moet

het project documentatie opleveren volgens de daarvoor geldende richtlijnen. Dit proces behelst

ook de goedkeuring van de programma stuurgroep, voor het overgaan in een volgende fase

en/of de start van het project. De projectleider zal tijdig de juiste informatie moeten opleveren

gedurende het hele traject van het project. Zowel in de voorbereidende fase van het project voor

het verkrijgen van toestemming om te starten als gedurende de fasen overgang is de

projectleider verantwoordelijk voor het opleveren van de bij deze fasen behorende

deliverables. Wanneer deze niet centraal worden voorgeschreven of vanuit het programma

gedicteerd zal een projectleider deze zelf vooraf op moeten stellen.

Methode; Voor het uitvoeren van projecten zijn diverse methoden beschikbaar. Het is in een

organisatie vaak verplicht een standaard methode te gebruiken, echter hebben de meeste

methodes de mogelijkheid om varianten te gebruiken indien deze beter voor een organisatie

uitpakken. Tevens is het mogelijk dat de methode verschilt bij variaties in grootte en

complexiteit van projecten. Zo zou een project met veel risico en complexiteit een andere

methode kunnen hanteren dan een project voor een upgrade van een release. Een groot

onderscheid in projectmethode kan bijvoorbeeld ook maatwerk (zelfbouw) ten opzichte van een

pakket keuze zijn.

Scope setting; Voor projecten is het erg belangrijk vast te leggen wat er opgeleverd gaat worden

en zeker ook wat niet opgeleverd gaat worden. Deze uiteindelijke vastlegging staat bekend als de

scope van een project. Voor alle partijen zal het duidelijk moeten zijn voor welk doel het project

opgestart is. Dat is in eerste instantie niet het belangrijkste, maar wel voor het tweede onderdeel

voor de projectuitvoer. Gedurende de projectlooptijd heeft elk softwareontwikkelproject de

neiging zijn doel enigszins te wijzigen. Flexibiliteit is een groot goed, maar er moet gewaakt

Pagina {52}

worden op het feit dat het gestarte project niet meer met goedgekeurde tijdslijnen en budget

uitkomt.

Planning; Zowel in documentatie als in datums, mijlpalen en doorlooptijd maakt de projectleider

een planning. Zij bepaalt de verschillende fasen en stemt af met alle betrokkenen hoe de

planning uiteindelijk er uit gaat zien. De projectleider houdt rekeningen met overlegstructuren

zoals het projectoverleg of projectleidersoverleg. Het is ook mogelijk dat er overleg plaatsvindt

met staffuncties als architectuur, PMO of governance groepen. Voor het opstellen van een

planning kan een projectleider vaak putten uit ervaring, al dan niet die van haarzelf of die van de

organisatie waarin zij zich bevindt. Los van het unieke karakter van elk project is er vaak wel

een soortgelijk project in het verleden uitgevoerd. Dit eerdere project kan dus als basis dienen

van het op te stellen project.

Workbreakdown structure (WBS); de (deel) taken benodigd om de deliverables te halen. De

kunst om het totaal op te leveren doel van een project in te delen naar fasen en behapbare delen,

ook wel taken genoemd. Hierbij komt een fase van intensief contact met leveranciers voor het

inschatten van de werkzaamheden en de duur van deze werkzaamheden.

BOM; Een goede houvast is een bill of material lijst. Dit is een lijst waarbij de op te leveren

deliverables in een boomstructuur wordt weergegeven. Niet alleen levert dit een goed

overzicht op van alle op te leveren onderdelen met eventuele ommissies, maar het levert ook

een mooie koppeling met de taken per onderdeel t.o.v. de scope van het project. Deze BOM

wordt echter niet vaak gehanteerd binnen een software ontwikkel project.

Gantt charts; Gantt Charts zijn een uitvinding van de ingenieur Henry Gantt (1861–1919), die

een visuele vorm van planning uitwerkte voor het Amerikaanse leger. Ze zijn tot op de dag van

vandaag een uitstekende manier van visueel uitwerken van fasen en de WBS voor projectleiders.

Elementen van de Gantt-grafiek zijn:

1. Begin en eindtijden van taken (specifiek een kolom met “duur”)

2. Geplande en actuele status van taken

3. Afhankelijkheden tussen taken

4. Kritische taken (taken liggend op het Kritieke Pad)

5. Mijlpalen

Pagina {53}

Figuur 14 Voorbeeld Gantt Chart

In het bovenstaande voorbeeld is het vrij eenvoudig het overzicht te zien. Dit kan overigens in

grotere planningen een stuk moeilijker zijn. In de figuur is te zien dat Taak D pas kan beginnen

als B is geëindigd. Tevens dat taak C achterloopt op de planning en dat D precies goed loopt.

PERT/CPM charts; CPM staat voor Critical Path Method. Het kritieke pad is de Idee le sequentie

van taken die resulteert in de kortste doorlooptijd voor het behalen van het eindresultaat. PERT

staat voor Program Evaluation and Review Technique, en is een methode die ontwikkeld is

door de Amerikaanse marine. Hierin worden de taken die uiteindelijk de doorlooptijd van een

project bepalen omdat deze sequentieel van elkaar afhankelijk zijn bepaald. Vervolgens wordt

gekeken hoeveel ruimte zich voor of na een taak bevindt als mogelijke buffer. Dit wordt ook wel

slack genoemd. De slack kan voor een kritiek pad activiteit zitten waarbij het pad van kritiek

niet onder vuur komt te liggen. Hierdoor is het eenvoudiger om te concentreren op het kritieke

pad, zolang de niet-kritieke taken maar tijdig worden gestart. In de praktijk wordt in een

software ontwikkel traject deze techniek niet toegepast. Een van de uitlopers van de PERT

techniek krijgt wel aandacht binnen deze methode, namelijk de door Goldratt geïntroduceerde

Theorie of Constraints techniek. Deze wordt besproken in proces 5.

Resourcing; Wanneer de planning gemaakt is en de taken zijn geïdentificeerd, zal bekeken

moeten worden wie deze taken uit moet voeren. In eerste instantie kan bij het uitwerken van de

planning reeds een rol worden toegewezen aan een taak. Dit is een algemene verwijzing naar het

feit dat wel reeds bepaald is welke groep mensen dit zou moeten kunnen uitvoeren, maar niet

specifiek wie. Wanneer een taak door meerdere mensen wordt uitgevoerd, kunnen ook

meerdere rollen worden aangewezen. Hierbij hoeft in eerste instantie nog niet de ervaring van

de persoon of skills te worden opgenomen. Een bouwtaak bij een software ontwikkelomgeving

hoeft niet reeds te vermelden dat het een Java ontwikkelaar met ervaring voor MQ-series betreft.

Dit zijn details voor een later tijdstip. Afhankelijk van het stadium van het proces waarin het

project zich bevindt zullen deze rollen meer vervangen moeten worden door de daadwerkelijke

personen die de uitvoer moeten verzorgen. Dit blijft in de praktijk een moeilijk proces, dat zich

ook tijdens het project vele malen zal laten gelden. Daarom wordt het ook apart in de CPM

methode opgenomen.

Budget; het budget is opgebouwd uit diverse aspecten. Hierbij is het mogelijk deze aspecten als

vast of variabel te definiëren. Benodigde hardware bij een ontwikkelomgeving of gebruik van

faciliteiten kunnen hier ook bij opgenomen worden. Het belangrijkste aspect bij de budgetten

Pagina {54}

voor bijvoorbeeld een software ontwikkeltraject is de inzet van personeel. Deze volgt dus direct

uit de planning en de resourcing.

Business Case; het budget levert de kosten die gemaakt moeten worden voor een project, maar

de baten zullen ook een rol spelen binnen het project. De projectleider is verantwoordelijk voor

het opstellen van een gedegen business case ter verantwoording van een project. Een

projectleider is meer dan een uitvoerder, er wordt tevens een beroep gedaan om het uitvoeren

van een project te rechtvaardigen. Het eigenaarschap van een business case is overigens niet de

projectleider zelf, maar veel eerder de opdrachtgever zelf. Niet alleen is dit de persoon die op

langere termijn voordelen van de wijziging ziet, maar ook degene die na de oplevering van het

project deze voordelen ook moet bewaken. Ultimo is de projectleider verantwoordelijk voor het

opstellen en periodiek bijhouden van de business case.

Risico; Het unieke karakter van een project brengt bij elk project weer een veelvoud aan

potentiële nieuwe risico’s. Deze zullen voor zover mogelijk van te voren gedefinieerd moeten

worden. Naast het benoemen van het risico zal er een kans gekoppeld moeten worden waarop

het risico kan optreden en eventuele maatregelen om het risico of de kans te verkleinen. Bij

goede planningen komt ook de te volgen koers wanneer een risico zich toch voltrekt, ondanks

alle mogelijkheden dit risico tegen te gaan.

Hierbij spelen twee soorten risico's die allebei betrokken moeten worden in het

aandachtsgebied van de projectleider:

1. Interne risico's. Dit zijn risico's die van invloed zijn op de door het project gedefinieerde

scope, kwaliteit, budget en mijlpalen. Het gebruik van nieuwe technologie kan een risico

zijn voor een project omdat de inschatting in tijd en capaciteit moeilijk te maken valt

door gebrek aan ervaring.

2. Externe risico's. Dit zijn risico's die voor een gebruikersorganisatie (opdrachtgever)

spelen op het moment dat het project uiteindelijk niet kan leveren. Als de oplevering van

een project dat als doel heeft de vervanging van een primaire applicatie vertraagd wordt,

kan het een risico worden voor de afhandeling van klanten binnen het oude systeem.

In de praktijk worden de risico's en de business case nauwelijks gekoppeld. In de uitwerking

van de processen zijn deze wel gekoppeld. Hierdoor is niet alleen inzage in de financiële

gevolgen van een risico, alsmede het eigenaarschap van risico's anders belegd. Zeker de tweede

categorie van risico's worden door een projectleider vaak genoemd in haar projectdocument,

maar het eigenaarschap niet als zodanig gevoeld.

Data van eerdere projecten; Alhoewel een van de karakteristieken van een project het feit dat elk

project uniek is, wil dit niet zeggen dat elk project het wiel opnieuw moet uitvinden. Projecten

volgen een vaste methode en werkwijze. Ze worden ondersteund door een PMO die

ondersteuning levert door het uitdragen van vaste standaards en processen. Hierbij komt ook de

mogelijkheid om vanuit eerdere soortgelijke projecten de informatie in te zien om realistische

inschatting van planning en budgetten te verkrijgen. Belangrijk voor een organisatie is het feit

dat projecten geleid worden door vakkundige projectleiders die in soortgelijke situaties reeds

een project uitgevoerd hebben.

Pagina {55}

Rapportages; Vooraf dient de projectleider reeds vast te leggen hoe de rapportages over de fasen

vorm moet krijgen. Wederom geldt hier dat dit zelfstandig opgesteld moet worden als deze niet

centraal door een PMO of door het programma is voorgeschreven. De rapportages die in de

volgende paragraaf worden beschreven zullen in de aanloop van de desbetreffende fase worden

afgestemd.

2. Reporting

Na het plannen zal de rol van de projectleider veranderen in voornamelijk het monitoren van

deliverables, voortgang, budget, scope en/of business case. De overgang is meestal niet

abrupt, maar voor het halen van planningen wordt naar een startdatum toegewerkt. Hierbij is de

onderstaande opsomming niet specifiek bedoeld als processen of taken die pas beginnen na een

projectmandaat, maar meer een overgang van planning naar operationeel. Bij de start van een

project is de bemensing en het budget reeds beschikbaar.

Planning; Planningen blijken in de praktijk weerbarstig te zijn en naar gelang een project groot

of complex is, hebben ze de neiging af te wijken van de vooraf ingeschatte tijd of tijdstippen. Een

projectleider stuurt vaak op het behalen van mijlpalen om een project op grote lijnen te sturen.

Hierbij moet veel overleg plaatsvinden om de planning van onderliggende deelprojecten ook af

te stemmen. Dit gebeurt vaak met de verantwoordelijke teamleiders, die elk weer hun deel van

de planning opleveren. Kanttekening hierbij is dat planning uitgedrukt kan worden in tijd, dus

een percentage uren dat gebruikt is, maar zeker ook in deliverables.

Bij het uitlopen van taken (tijd of deliverable) zal een projectleider voornamelijk scherp

moeten opletten of dit van invloed is op het kritieke pad, waardoor het project met zekerheid

uitloopt in tijd. Niet-kritieke taken kunnen door uitloop overigens ook op het kritieke pad

terechtkomen. Vaak is het voor een projectleider bij voorbaat moeilijk om te beslissen of een

niet-kritieke taak moet starten op de vroegst mogelijke startdatum of de laatst mogelijke. Nadeel

van de eerste is mogelijk verlies aan concentratie en inefficiëntie, nadeel van de tweede is dat er

een taak gecreëerd is dat bij voorbaat ook op de kritieke pad ligt. Hierbij refereren we graag

naar Goldratt the Critical Chain theorie. Deze theorie wordt besproken als mogelijke methode

in proces 5, waarbij het Tactische Portfolio wordt vastgesteld.

Daarnaast zal een projectleider een overzicht moeten hebben om de afhankelijkheden tussen

taken goed in kaart te kunnen hebben. De eerder genoemde Gantt-grafieken geven de

afhankelijkheden weer van de verschillende taken. Een projectleider zal deze grafiek up-to-date

moeten houden om verschuivingen in de planning te kunnen opvangen vanwege deze

afhankelijkheden.

Bij de hulpmiddelen van de projectleider zijn Gantt-grafieken ook ideaal om ‘what-if’ scenario’s

te spelen met ad hoc aanpassingen voor bijvoorbeeld wijzigende bezettingen, uitlopende taken

en blokkades.

Voor een projectleider zijn de externe afhankelijkheden buiten het project de moeilijkste zaken

om rekening mee te houden. Wanneer een project afhankelijk is van bijvoorbeeld de oplevering

van een ander project, zal deze afhankelijk bewaakt moeten worden. Wanneer er veel

afhankelijkheden bestaan die ook niet beïnvloedbaar zijn door het programma, kan hier een

complex geheel ontstaan.

Pagina {56}

Deliverables; De projectleider moet gedurende de verschillende fasen van haar project de

diverse deliverables opleveren conform afspraak. Deze zijn vooraf gedefinieerd en afgestemd

met de betrokken partijen. Voorbeelden zijn Project Start Architecturen (PSA) gedurende een

vooronderzoek fase en de gebruikershandleiding in de Gebruikers Acceptatie Test (GAT) fase.

Afhankelijk van de fase worden hier ook specifieke rapportages over opgesteld. Zo zijn er tijdens

een Functionele Acceptatie Test rapportages op te leveren over de geteste objecten die de

voortgang van de testen inzichtelijk maken.

Budget; Het vastgestelde budget zal voor de vaste kosten pas in gevaar komen wanneer er

additionele kosten bijkomen die niet van te voren ingeschat (konden) worden. Tussentijdse

prijsverhogingen of een mogelijke uitbreiding op de scope (zie kopje issues en changes) niet

meegenomen.

Het variabele gedeelte komt binnen een software ontwikkelproject, zoals gezegd, voornamelijk

terecht bij de inzet van personeel. Dit wil zeggen dat de projectleider gedurende het project goed

de inzet van zijn teamleden moet meten t.o.v. de geplande inzet. Binnen de project management

wereld zijn hiervoor de termen:

Planned; alle uren die van te voren ingeschat zijn voor de uitvoer van een gegeven taak.

Burned; alle uren die tot nu toe daadwerkelijk gebruikt werden voor een gegeven taak.

Dit wordt ook wel actuals genoemd.

Earned Value Analyse; De Earned Value Analyse is een methode waarin de planning, de scope

en de kosten van een project tegelijk inzichtelijk worden gemaakt. De klassieke methode voor

het besturen en analyseren van een project is het opstellen van een planning vooraf, deze goed

te keuren en vervolgens de monitoren via de hoeveelheid kosten die gemaakt worden. Deze

inschatting van de hoeveelheid kosten is ook nog vaak het aantal ingeschatte uren en niet zozeer

de daadwerkelijk kosten die daarbij gemaakt worden. Het grote manco in dit verhaal is het feit

dat bij een afweging van actuals vs budget niet de kwaliteit of de mate waarin de deliverable

daadwerkelijk klaar is, is meegenomen.

De EVA is een methode waarin de objectieve en kwantitatieve resultaten worden gemeten.

Hierbij worden de volgende meeteenheden gebruikt:

Planned Value; Dit is de geplande hoeveelheid budget die nodig is voor het uitvoeren van een

project of van een gedeelte ervan.

Actual Cost; Dit zijn de totaal gemaakte kosten in de periode waarin gemeten wordt, de

verbrande uren die geschreven zijn.

Earned Value; De waarde van de deliverables in de gemeten periode, dus de hoeveelheid

gereed werk maal de gebudgetteerde kosten daarvan.

Budget Variance; het verschil tussen de Planned Value en de Actual Cost, waarbij het verschil

in geld wordt uitgedrukt zonder in de opgeleverde hoeveelheid deliverables te duiken. In

formule vorm levert dit BV = PV – AC.

Cost Variance; het verschil in kosten waarbij de gecreëerde waarde wordt afgewogen tegen de

bestede kosten. In formule vorm: CV = EV – AC.

Pagina {57}

De EVA methode gaat veel verder dan in bovenstaande paar formules wordt samengevat.

Conclusie hieruit is dat deze methode in de praktijk steeds vaker gebruikt wordt omdat het

zowel de tijd (kosten) in de gaten houdt als de voortgang van de deliverables. Voor een bredere

uitleg is deze methode uitgewerkt op de accolades website.

Resourcing; Bij het concretiseren van een project, dit kan al voor de projectmandaat, wordt het

bemensen van een project steeds urgenter. Voor het bemensen zijn in de praktijk twee

processen normaal, het informele en formele traject. Het eerste is specifiek gericht op personen

die de projectleider reeds kent en graag bij zijn project (weer) wil betrekken. Hierbij zijn

informele afspraken de initiatie van de aanvraag, waarbij de afstemming vaak al gedaan is

voordat het officiële traject gestart wordt. Bij de tweede vorm wordt het officiële traject

opgestart zonder specifiek persoon in gedachte. Hierbij wordt het proces gebruikt als vraag

richting de leverancier om een persoon te regelen die voldoet aan een profiel met vooraf

gespecificeerde kenmerken. Deze kenmerken bestaan uit vaardigheden en kennis waar een

persoon aan moet voldoen en een indicatie van het aantal dienstjaren waar deze persoon deze

kennis of vaardigheden gebruikt heeft.

Het aanhaken van leveranciers is een taak op programma niveau. Deze leveranciers zijn namelijk

vaak ook de stakeholders bij een project en zijn als zodanig ook betrokken bij het proces

gedurende de looptijd van een project. De afspraken en het officiële proces rondom resourcing

is onderdeel van de governance van het programma.

De tijdige inzet van personeel op de eerder vastgestelde takenlijst, is een constant risico van een

projectleider. Zeker bij grote projecten zal er zeker verloop zijn in het personeel, hetzij binnen

de organisatie, hetzij hierbuiten. Wanneer de planning onder druk komt te staan is de inzet van

meer personen met dezelfde skillset een standaard wijze van opvang. Dit is echter niet vaak een

garantie van het wegwerken van achterstand.

Tevens zal de flexibele inzet van personeel vaak buiten de organisatie gezocht moeten worden.

Deze inzet neemt tevens een ander kostenplaatje met zich mee. Daarbij een mogelijk issue op

het gebied van planning aangezien nieuw personeel op tijd geleverd en ook ingewerkt moet

worden.

Business Case; Naast het bijhouden van de budgetten zal ook periodiek gekeken moeten worden

of de baten ook nog steeds actueel zijn. Zowel de projectomgeving als de wereld eromheen

verandert gedurende de loop van een project. Dit is primair niet de focus van een projectleider

en het bijhouden van een business case zal dus afgedwongen moeten worden. Daarbij is het

zaak dat de projectleider ook ondersteunt wordt in het ophalen van informatie over de baten,

aangezien dit vaak niet tot het kennisdomein van de projectleider hoort. Wat wel standaard bij

de werkzaamheden hoort is de impact van interne verschuivingen op de business case.

Wanneer een project later opgelevert wordt is niet alleen het verhoogde budget een factor,

maar ook de starttijd waarop begonnen kan worden met het terugverdienen.

Issues; Voor het goed hanteren van onverwachte zaken hanteert de projectleider twee

categorieën van wijzigingen. De eerste zijn issues, gedefinieerd als (on)verwachte invloeden op

de planning, kwaliteit of budget. Hierbij bestaat het onverwachte uit alle zaken waar van te

voren geen rekening mee gehouden kon worden en het verwachte zijn issues voortkomend uit

de risicolijst. Alle issues kunnen een project ernstig hinderen en dienen besproken te worden

Pagina {58}

binnen het project. Deze moeten gecategoriseerd worden of deze blokkerend zijn voor het

project en zonodig opgelost worden. Wellicht ligt de oplossing hiervan buiten het project en

moeten op in een ander gremium worden neergelegd.

Changes; Changes zijn zaken die niet van te voren zijn meegenomen en die het project in min of

meerdere mate beïnvloeden in tijd, de scope van het project, het budget of de kwaliteit. Dit zijn

zaken die niet noodzakelijk opgelost dienen te worden, maar in overleg met de opdrachtgever

mogelijk wel worden meegenomen. Dit zal altijd gepaard gaan met een verandering in budget of

doorlooptijd (of beiden). Voor wijzigingen van de scope is vanuit het Engels hier de term

scopecreep geïntroduceerd. Er is niets mis met deze scopecreep, zo lang er genoeg geld is voor

het project. Scopecreep ontstaat tenslotte door de (gewijzigde) wensen van de opdrachtgever

zelf. In de omgevingen waar ook gebruik wordt gemaakt van ITIL terminologie, waar ook de

term changes wordt gebruikt, zal er verwarring ontstaan tussen beide soorten changes. Ze

hebben beiden namelijk een ander traject te belopen qua governance, waarbij het ITIL proces

vele malen stringenter is dan die van een project. De controle ligt ook vaak buiten de handen van

het project. Het is uitermate zinvol om binnen een programma beide stromen apart te benoemen

en te rapporteren. Het beste is ze beiden ook anders te noemen.

Proces; Gedurende de uitvoer van een project is de projectleider ook verantwoordelijk voor het

volgen van de processen waar het project zich aan moet houden. De hiervoor genoemende

changes zijn een goed voorbeeld van het volgen van het juiste proces. Afwijkingen van de

afgestemde lijn dienen te worden ondersteund met goedkeuring. Afhankelijk van de gebruikte

methode wordt dit ondersteund met afwijkingsrapportages of Request for Changes. Een aparte

tak van sport is het plannen van de go/nogo momenten binnen een project. Het afstemmen wie

hiervoor welk mandaat heeft en op basis waarvan deze beslissing genomen dient te worden is

een niet te onderschatten bezigheid. De benodigde duidelijkheid dient zo vroeg mogelijk bepaald

te worden. In de praktijk zal hier pas over nagedacht worden wanneer zo'n moment in de nabije

toekomst zich voordoet. Zelden zal dit in een voorbereidend stadium worden gepland.

Risico's; Tijdens de uitvoer van een project zal de projectleider tevens de bij de planning

opgestelde risico’s moeten managen. De inschatting van risico’s en de kans op het optreden

hiervan kan gedurende het project wijzigen. Hieraan geven sommige projectmethodes veel

aandacht door het op vaste tijden bijwerken van de risico log. Zoals later zal besproken worden

is het zinvol om nieuwe risico's op te laten voeren door meerdere mensen binnen het project en

is het beoordelen hiervan een taak van de stuurgroep. Daarbij is het zaak om de benoemde

risico's te koppelen aan de business case zoals hiervoor beschreven.

H. Hulpmiddelen Zoals beschreven in E bij de CCMI niveaus zal bij de volwassenheid van de processen op enig

moment sprake zijn van hulpmiddelen ter ondersteuning. Variërend van ouderwetse

planborden op de muur achter de persoon die verantwoordelijk is voor de inzet van service

mensen, tot de whiteboards gebruikt om planningen te communiceren, is er een groot scala aan

hulpmiddelen in te zetten om projecten en portfolio’s te ondersteunen.

Om een goede indruk te krijgen van de beschikbare geautomatiseerde tools is het niet

noodzakelijk om hulpmiddelen die te algemeen zijn, zoals MS Word, of die niet noodzakelijk

daarvoor gecreëerd zijn, zoals tekentools, hierbij op te nemen. Wel zal binnen elke organisatie

een tool geschikt voor het maken van grafieken, tabellen en overzichten beschikbaar moeten

Pagina {59}

zijn. Voor het gemak is het gebruik van een whiteboard en post-its niet meegenomen. Hierbij

moet zeker niet onderschat worden dat een plaatje op een whiteboard of het gebruik van post-

its voor een scrum methode erg bruikbare hulpmiddelen zijn. Echter zijn dit niet het soort

hulpmiddelen op basis waarvan een PMO of Portfolio Manager mee overweg kan om bruikbare

beslissingen te maken over de soort en aantal projecten in zijn of haar portfolio.

Binnen deze paragraaf zal een beschrijving gegeven worden van die tools die in de praktijk

ingezet worden op de verschillende CMMI niveaus. Aangezien er zeer veel hulpmiddelen zijn

voor project en Project & Portfolio Management is het onmogelijk allen te benoemen. De

hulpmiddelen zijn gegroepeerd in karakteristieke kenmerken, waarbij de kanttekening gemaakt

kan worden dat sommige tools meer kunnen dan de categorie waarin ze hier geplaatst worden.

Vaak zal in de praktijk, zeker wanneer de hulpmiddelen zelf nog niet op CMMI niveau 3 zijn

ingeregeld, een combinatie van hulpmiddelen gebruikt worden. Dit brengt echter een enorm

gevaar met zich mee dat de waarheid van projecten nooit echt met zekerheid kan worden

vastgesteld. Tenzij stringente regels en processen zijn opgesteld, maar ook hier geldt de wet van

Murphey.

1. Spreadsheet

Microsoft Excel, of varianten als Lotus 123, is met afstand de meest gebruikte tool om

planningen op te stellen en bij te houden. Een spreadsheet is vrij eenvoudig op te stellen en kan

grafisch al snel overzichten en rapportages aanbieden.

In Excel kan met geringe inspanning op hoog niveau een planning geschreven worden. Het vergt

echter veel inspanning om van een planning op hoog niveau tot een gedetailleerde planning te

komen. Excel leent zich goed voor het uitwisselen van lijsten met gegevens, bijvoorbeeld met het

doel de wekelijkse status af te geven. Het leent zich weer minder voor het aggregeren van

dergelijke gegevens in een overzichtsplaat.

Los van het detailleren op taakniveau, is het ook lastig om resources aan taken te koppelen. Het

kost veel tijd om een betekenisvolle koppeling (meer dan een celverwijzing) te maken tussen

taken en resources, vooral als de toewijzing stand moet houden als taken schuiven in de tijd.

Hetzelfde geldt voor mijlpalen en deliverables in het algemeen.

Bij het maken van wijzigingen aan de planning maakt het relatief weinig uit of het gaat om een

gehele nieuwe planning, het schuiven in de tijd van taken of het wijzigen van de structuur van de

planning. In alle gevallen biedt Excel rudimentaire ondersteuning (knippen/plakken), zonder

intelligentie om tijdspannes door te rekenen of nieuwe kritieke paden te herkennen.

Om diezelfde reden is het moeilijk om “what if” scenario’s uit te voeren met Excel. Rapportages

moeten van de grond af opgebouwd worden. Daarbij heeft de inhoud van een cel geen betekenis

voor Excel: een datum is een datum, en er moet handmatig gerekend worden met begin, eind of

gewijzigde datums.

Los van het bijhouden van de planning op zich, is ook het bijhouden van versies van de planning

of het bestand bij gebrek aan baselines tijdrovend en met gevaar van vervuiling.

Pagina {60}

Ten slotte maakt de structuur van gegevens in Excel het mogelijk die gegevens te exporteren,

maar het is lastig er betekenis aan te hechten.

Helaas wordt Excel vaak gezien als het 1000-dingen-doekje. Aangezien het zoveel functionaliteit

met zich meebrengt, wordt de tool ook vaak misbruikt voor zaken die duidelijk niet daarvoor

gemaakt zijn. Zo is een spreadsheet geen database, maar ook zeker geen hulpmiddel dat alles

kan voor een projectleider. Grootste gevaar in deze is het versiebeheer rondom gekoppelde

spreadsheets. Wanneer verschillende mensen, evenzoveel spreadsheets onderhouden en

aandragen voor een overkoepelend overzicht is het de vraag of de waarheid getoond wordt.

2. Grafiek hulpmiddelen

Om grafisch beter voor de dag te komen is het mogelijk tools in te zetten die niet alleen beter

ogen, maar ook met rudimentaire zaken beter functioneren. Ze zijn gemaakt om

projectmanagers beter bij te laten houden wat de planning is voor zijn project. Er zijn diverse

pakketten te koop die verschillende soorten grafieken ondersteunen, waaronder de Gantt

grafiek, maar ook PERT/CPM technieken. Vaak zijn ze uitgerust met diverse rapportage

faciliteiten, zoals exporteren naar pdf formaat, Excel, html, etc..

Voorbeelden van grafische hulpmiddelen voor projecten zijn:

Milestone Simplicity (http://www.kidasa.com/)

GanttProject (http://www.ganttproject.biz/ )

Smartdraw (http://www.smartdraw.com )

Figuur 15 Voorbeeld Milestone Simplicity

Deze hulpmiddelen zijn voornamelijk voor de individuele gebruiker. Een projectleider zal een

versie locaal op zijn PC draaien in een stand-alone omgeving. Informatie komt verbaal bij de

projectleider die een update geeft door het bijwerken van het bestand. Wijzigingen zoals later

starten van taken en doorschuiven van werk zijn eenvoudig door te voeren.

Pagina {61}

Verder zijn er weinig faciliteiten voor bijvoorbeeld resourcemanagement. Hierdoor is een up-

to-date rapportage over de gewerkte uren t.o.v. de planning veel werk wanneer de taken zeer

gedetailleerd worden weergegeven. Veel van deze tools (niet allen) hebben verder geen

mogelijkheden voor issuemanagement, risico management, budgettering of afhankelijkheden

tussen projecten.

Versie beheer is een uitdaging bij deze tools omdat het vaak één vorm van de waarheid

weergeeft. Het betreft de huidige waargenomen stand van zaken m.b.t. een project of een groep

van deelprojecten.

3. Projectplanning

Wanneer een project complexer wordt, is de ondersteuning van project planning pakketten een

toegevoegde waarde. Het ziet er visueel uit als een grafisch hulpmiddel van de vorige paragraaf,

maar biedt meer waarde in functionaliteit. Vaak hebben de grafische applicaties ook een

duurdere variant die deze functionaliteit ook ondersteunt.

De kracht van Excel zit in de flexibiliteit en de eenvoud waarmee formules gedefinieerd en data

verwerkt kan worden. Project planning software heeft als voordeel dat berekeningen (zoals de

eerder beschreven earned value analyse) al ingebouwd zijn en ze biedt ondersteuning voor

scenario’s en resource scheduling/leveling. De ondersteunde functionaliteit t.o.v. grafische

hulpmiddelen of een spreadsheet zijn o.a.:

1. Kritieke Pad berekeningen

2. Earned Value Analyse

3. Afhankelijkheden tussen taken

4. Resource toewijzing

5. Rudimentaire scenario ondersteuning

Project planning software vervult een specifiek doel tegenover het generieke werkveld van

Excel. Hierdoor mist Excel functionaliteit op het gebied van flexibiliteit in het aanbrengen van

wijzigingen (taak/subtaak structuren verplaatsen in Project tegenover rijen kopiëren en plakken

in Excel) traceerbaarheid van wijzigingen (baselines in Project geven meer overzicht dan

“wijzigingen bijhouden” in Excel) en zowel overzicht als eenduidigheid in weergave (Gantt- of

netwerkdiagrammen tegenover kolommen met data, gekleurde cellen of een andere oplossing in

Excel).

Deze specifieke doelstelling van project planning applicaties heeft wel tot gevolg dat het

programma aan een kleinere groep gebruikers beschikbaar wordt gesteld. Voor het

communiceren van de planning kan er alsnog met een conversie via Excel of publicatie via pdf of

het web gewerkt worden.

Voorbeelden van project planning applicties:

Project Vision (http://www.visionproject.se/)

Openproj (http://sourceforge.net/projects/openproj/)

Pagina {62}

MS projects (http://www.microsoft.com/project/en-us/project-management.aspx)

Open Workbench (http://sourceforge.net/projects/openworkbench/)

4. Inzet PPM tools

De voordelen van Project & Portfolio Management (PPM) tools boven het gebruik van

combinaties van Excel, MS Project, een resource tool en een urenregistratie tool zijn te verdelen

in twee groepen, de kwaliteit van de informatie en de kosten gepaard met het gebruik. Ongeacht

welke tool hiervoor gekozen wordt, levert basisfunctionaliteit van Project & Portfolio

Management tools:

1. Portfolio Planning; alle tools behulpzaam voor het uitvoeren van processen op een groep

van projecten.

a. Budgettering van (deel)projecten.

b. Analyses op projecten in het geheel van de portfolio.

c. Scenario’s bouwen en uitvoeren.

2. Projectplanning

a. Creëren en bijhouden van projectplanningen. Hierbij spelen zaken als

collaboratie, mijlpalen inzichtelijk maken, Earned Value Analyse gebaseerd op

actuele stand van zaken en het bijhouden van specifieke taken binnen het

project.

b. Planningen bijhouden van key-tasks, Work Breakdown Structures (WBS), tijd

schattingen, afhankelijkheden, deliverables en toewijzen van personeel.

c. Het gebruik van templates en best-practices in het opzetten en beheren van

projectplanningen.

d. Integratie van project resourcing en kosten allocaties.

e. Uren registratie op taak niveau voor geautoriseerde gebruikers. Deze zijn

geaccumuleerd weergegeven op het hoogste informatieniveau.

f. Werkprocessen automatisering voor in ieder geval de basisprocessen als

timesheet notificatie, budget aanvragen, bijwerken van toekomstige planningen,

resource allocatie en documentatie routering en autorisatie.

g. Analyses en traceren van tijd en kosten op taak niveau over deelprojecten heen.

h. Managen van risico, issues en functionele wijzigingen, inclusief de daarvoor

benodigde budgetten en resources.

3. Financial Management; Alle processen behorende bij het financieel verwerken van

door projecten geïnitieerde kosten.

a. Facturering en betalingen van alle inzet van externe, gebruikte resources en

algemene kosten.

b. Chargeback kosten berekening voor het gebruik van resources vanuit de lijn,

maar ook van services richting eindgebruikers.

c. Kosten ramingen en kostprijs matrices gebruik. Voor verschillende soorten

kosten (personeel, materiaal, onkosten en apparatuur) is het gebruik van kosten

soorten en variaties mogelijk.

4. Resource Management; Alle activiteiten, informatie en processen vanuit een HR positie.

a. Matchen van personeel met de aanvragen vanuit een project.

b. Balanceren van project aanvragen en de beschikbare resources in een

organisatie.

Pagina {63}

c. Afhandelen van resource aanvragen voor projecten.

5. Demand Management; het aanvragen, behandelen en accepteren van aanvragen vanuit

de gebruikersorganisatie.

a. Systematisch opvangen en evalueren van vraag vanuit gebruikersorganisatie.

b. Het correct managen van nog ongepland werk.

c. Begrijpen en managen van de daarbij behorende kosten.

Bij de standaardfunctionaliteit komen ook aspecten m.b.t. de mogelijkheden om integratie met

andere omgevingen te bewerkstelligen en aspecten om deze basisfunctionaliteit te faciliteren.

Voor het koppelen met pakketten moet gedacht worden aan:

1. Financieel pakket; Vaak wordt de financiële afhandeling uitgevoerd door een

standaardpakket (bijvoorbeeld SAP). Hierdoor zijn koppelingen met SAP standaard voor

de meeste CPM pakketten.

2. HR systemen; De meeste organisaties hebben ook HR systemen waar de medewerkers

reeds ingevoerd zijn. Hierdoor is het wenselijk om de resources vanuit dit HR systeem

te laten aansluiten op het CPM pakket.

3. Projectplanning pakketten; Vaak zijn projectleiders gewend geraakt aan het werken met

projectplanning pakketten als MS Projects. Hiervoor zijn integratiemogelijkheden

gecreëerd in de meest gangbare CPM pakketten. Voordeel is dat een projectleider blijft

werken met zijn/haar gewenste tool waarbij deze vaak stand-alone gebruikt kan

worden.

4. Collaboration Tools; Binnen de ICT zijn enkele hulpmiddelen opgekomen die onder de

term collaboratie gevangen worden. Dit zijn vaak webgebaseerde portal omgevingen die

functionaliteit met zich meebrengen als:

a. Document Management

b. Web Content Management

c. Records Management

d. Collaboration

En voor het faciliteren van de basisfunctionaliteit:

1. Workflow Management; Het kunnen modelleren van bedrijfsprocessen met o.a. keuze

methodes, autorisatie en selectie processen en tolhekfaciliteiten.

2. Reporting; Het kunnen printen of visualiseren van verschillende soorten rapportages.

Dit kan standaard of ad hoc gebruik van zowel af te drukken rapporten als via Portal

technieken.

Naast de basisfunctionaliteit zijn er verschillende soorten modules die zaken ondersteunen die

niet gangbaar zijn in alle PPM producten. Hierbij komt de visie van de PPM software leverancier

sterk naar boven, zeker op het gebied van Strategisch en/of Service Portfolio management.

Vanuit de leveranciers met traditioneel sterke service of beheer omgeving affiniteit komen de

volgende functionaliteiten als extra:

1. Aansluiting op helpdesk tools; Hierdoor is het mogelijk om issues direct in te voeren en

door te koppelen aan resources vanuit de IT lijn of IT projecten die ook hier uren op

kunnen registeren.

Pagina {64}

2. Aansluiting op Service Management tools; Dit om aan te sluiten op de beheer

processen van de meest gangbare frameworks als ITIL, ASL of COBIT. Aangezien dit een

veelvoud aan tools betreft (Asset Management, SLA Management, etc.) wordt deze

hier samengevat onder de kop Service Management Tools.

Voor aansluiting binnen het Project Portfolio Management domein is het facultatief mogelijk aan

te sluiten op versiebeheer hulpmiddelen. Hierbij is het mogelijk om specifieke taken te koppelen

aan software sources. Hierdoor is het ook mogelijk om niet alleen te sturen op tijd, gepland

versus actueel, maar ook op deliverables.

Vanuit de leveranciers die meer op het strategische vlak zijn er functionaliteiten als:

1. Aansluiting op Idee tion tools. Dit zijn hulpmiddelen specifiek gericht op het

registreren, accepteren en uitwerken van ideeën richting het lanceren van producten.

2. New Product Development; Voor organisaties met een grote Research &

Development afdelingen wordt er vaak gebruik gemaakt van methodes ter

ondersteuning van het beheersbaar maken van het ontwikkelen van nieuwe producten.

De bekendste methode hierin is het Stage Gate (Cooper, 1986)concept.

Er zijn diverse applicaties die PPM ondersteunen en het vergt teveel ruimte om dit in deze voor

te doen. Hieraan verdient Gartner veel geld om dit uit te voeren. Op wikipedia zijn voorbeelden

van project management tools te vinden en een kort vergelijk daarbij uitgevoerd. Los hiervan

zijn er heel veel tools die een onderdeel uitvoeren of rudimentaire ondersteuning bieden aan

projecten. Tel daarbij de vele mogelijke vormen op van aanbiedingen (o.a. SaaS aanbiedingen

van deze applicaties via internet) en je hebt een enorm scala aan mogelijkheden.

Wikipedia http://en.wikipedia.org/wiki/Comparison_of_project-management_software

http://nl.wikipedia.org/wiki/Programmatuur_voor_projectplanning

Pagina {65}

I. Stellingen Voordat in het eerste deel een begin wordt gemaakt met de theorie van mijn CPM methode, wil

ik eerst nog drie stellingen weergeven die als basis dienen voor de uitwerking. Uiteraard gaat de

praktijk in sommige organisaties mogelijk anders dan de volgende regels, maar dan zijn er twee

vragen te stellen: waarom wijkt mijn organisatie af van deze regels? Denk ik anders over de

regels wanneer ik dit boek doorgelezen heb?

Binnen de hierna uitgewerkte CPM methode gelden de volgende regels voor Portfolio

Management:

1. Een project is altijd gekoppeld aan een programma. Dit wil zeggen dat een project nooit

gestart kan worden zonder dat er een strategisch doel aan ten grondslag ligt.

Uitzonderingen zijn issues vanuit operationeel beheer waarbij de urgentie zodanig is dat

het vanuit productie opgelost moet worden. Dit zal binnen de methode apart worden

uitgewerkt. In de praktijk zal defacto de programma’s kostenbesparing, efficiency

verhogen en risico verlagen onderdeel vormen van het programma management.

Volgens het NBC vallen deze onder de multi-project noemer.

2. Elke applicatie heeft een Release Kalender. Deze Release Kalender geeft aan wat de

verander kalender in versies en wijzigingen is, specifiek voor de desbetreffende

applicatie. De Release Kalender moet afgestemd worden met de projecten die ook een

impact hebben op dezelfde applicatie. Een mooi voorbeeld is bijvoorbeeld wanneer er

wijzigingen komen in de interfacing van en naar een applicatie. Deze afstemming wordt

niet specifiek meegenomen in de Release Kalender, aangezien de Release Kalender

wordt opgesteld vanuit het oogpunt van de eindgebruiker. Deze afstemming moet wel

meegenomen worden bij het Project Portfolio Management.

3. Projecten behorende bij een Release Kalender worden als gewone projecten gezien en

opgenomen in de lijst van alle projecten. Dus niet als vaststaand feit of slechts als

onderdeel van het Service Portfolio Management proces. Dit aangezien de projecten

die gekoppeld worden aan een Release Kalender ook wedijveren om dezelfde resources

en budgetten als losstaande projecten. Tevens staat de Release Kalender los van

eventuele ideeën m.b.t. verbeteringen, ook al hebben deze verbeteringen mogelijk

betrekking tot dezelfde applicatie.