Magazine: Tijdschrijft IT Management Date: 10-2010 Author: Herman Limburg

1. 24 t i j d s c h r i f t i t m a n a g e m e n t24 t i j d s c h r i f t i t m a n a g e m e n t24 t i j d s c h r i f t i t m a n a g e m e n t
Hoezo over
de schutting?
itproject of
theyear
>>>>Quickscan
• aftiklijst
• samenwerking
• afstemming
• case overheid
thema
Waarom voltrekken implementaties van nieuwe IT-producten en -diensten zich vaak moeizaam,
lopen projecten altijd uit? Waarom leven business, beheer en ontwikkeling altijd op gespan-
nen voet met elkaar en hoe kan de projectorganisatie in dit spanningsveld succesvol zijn? Dit
artikel staat stil bij deze herkenbare problemen en presenteert een werkwijze, Transition-to-
Support, die de samenwerking tussen de business, beheerorganisatie, ontwikkelorganisatie en
de projectorganisatie verbetert. Tekst Herman van Limburg

2. o k t o b e r 2 0 1 0 25
D
e Transition-to-Support-werkwijze
houdt onder andere in dat iedere
partij voor zich bepaalt wat zij ten
behoeve van nieuwe diensten wil/
moet doen (activiteiten) en wat zij concreet van
anderen nodig heeft of zelf moet realiseren
(deliverables). Dit resulteert per partij in een af-
tiklijst en een overdrachtsdocument (zie figuur
1). Wanneer de drie aftiklijsten goed op elkaar
afgestemd zijn, zal er geen onduidelijkheid meer
optreden over wie wat wanneer gaat doen en
kan het project op een gestructureerde wijze een
nieuw product of dienst implementeren.
Dit artikel geeft een voorbeeld van hoe je de
samenwerking tussen de business, ontwikkel-
organisatie, beheerorganisatie en projectorga-
nisatie tijdens de realisatie van IT-producten en
-diensten kunt optimaliseren. Hierbij worden
tips gegeven die bij de implementatie nuttig
kunnen zijn.
Praktijk
In 2008 is bij een overheidsinstelling een start
gemaakt met de uitwerking van de Transition-
to-Support-werkwijze. Hierbij is begonnen met
de samenwerking tussen project, beheer en
ontwikkeling (zie figuur 2).
De beheerorganisatie heeft met behulp van een
aftiklijst aan de ontwikkel- en projectorganisa-
tie aangeven wat zij van de ontwikkelaars no-
dig had, maar ook wat zij zelf moest realiseren
om een dienst te kunnen leveren en beheren.
Door deze werkwijze begrepen de ontwikke-
laars wat er bij de in beheername van dien-
sten kwam kijken. De projectorganisatie wist
daarnaast wat zij ten behoeve van haar project
moest realiseren, om decharge te krijgen vanuit
beheer. En de beheerorganisatie zelf kreeg
beter inzicht in wat zij nodig had voor haar be-
heerwerkzaamheden. Hierdoor is de spanning
tussen de partijen afgenomen en had beheer
niet meer het gevoel dat nieuwe producten en
diensten ‘over de schutting’ werden geworpen.
Belangrijker echter nog was dat de nieuwe
IT-dienstverlening sneller en met een hogere
kwaliteit aan de business werd opgeleverd.
Aandachtspunten
Wat was er nu concreet nodig om de werkwijze
te implementeren? Om de samenwerking tus-
sen de drie partijen (Beheer, Ontwikkeling en
Project) te stroomlijnen, is vanuit de beheer-
organisatie gedurende enkele maanden de
aandacht op drie aspecten gelegd:
1. Middelen
2. Communicatie
3. Mensen
Ad1. Middelen
Het begin bestond uit de realisatie van enkele
middelen, zoals een beheeraftiklijst (zie note),
een template overdrachtsdocument, en pro-
cedures ter realisatie van enkele deliverables,
inclusief een escalatieprocedure.
Belangrijk bij de beheeraftiklijst is dat de
verschillende keyplayers binnen de beheer-
organisatie zelf de activiteiten en gewenste
deliverables beschrijven. Uitgangspunt hierbij
is dat de omschrijving zo concreet beschreven
moet zijn, dat iedere nieuwkomer (projectlei-
ders wisselen nog wel eens) direct begrijpt wat
er gedaan en opgeleverd moet worden.
Het overdrachtsdocument zorgt ervoor dat de
projectleider vanuit Beheer officieel decharge
kan krijgen. Vervolgens kan hij naar de pro-
jectboard gaan om overall decharge vanuit alle
afdelingen te krijgen.
Tevens zijn er procedures nodig, omdat er
regelmatig discussies ontstaan tussen ontwik-
kelaars, beheerders en projectleiders over de re-
alisatie van specifieke deliverables: wie maakt,
wie reviewt? Et cetera. Zodoende is er gekozen
voor de realisatie van dergelijke deliverables
(bijvoorbeeld UC’s, OLA’s, SLA’s DAP’s, AK-
analyses) in procedures uit te werken.
Project
DELIVERABLES
t.b.v. ontwikkeling
business
Ontwikkeling
(applicatiebe-
heer)
Business
(functioneel
beheer)
DELIVERABLES
t.b.v. beheer
ontwikkeling
Ontwikke-
lings-
overdrachts-
document
Beheer-
aftiklijst
Business-
overdrachts-
document
Business-
aftiklijst
Ontwikkel-
aftiklijst
Beheer-
overdrachts-
document
DELIVERABLES
t.b.v. beheer
business
Beheer
(technisch beheer)
Figuur 1. Samenwerking: business, beheer, ontwikkeling, project.
beheer had
niet meer
het gevoel
dat nieuwe
producten
en diensten
‘over de
schutting’
werden
geworpen...

3. 26 t i j d s c h r i f t i t m a n a g e m e n t
Wat echter ook heel belangrijk is, is het docu-
mentbeheer. Op alle drie de afdelingen werden
documenten op verschillende wijzen beheerd
met aparte rechtenstructuren. Hierin is dan ook
de nodige tijd geïnvesteerd om uiteindelijk de
beheerorganisatie de juiste rechten te laten ver-
krijgen op de documentstructuur bij de project-
organisatie. Het was handiger wanneer er een
gestructureerd documentmanagementsysteem
(MS SharePoint bijvoorbeeld) was geweest.
TIP: Gebruik, indien mogelijk, een document-
managementsysteem waarmee de partijen
documenten kunnen uitwisselen.
Ad 2. Communicatie
Qua communicatie heeft de nadruk op de aftiklijst,
de maandrapportage en de werkafspraken gelegen.
Ten behoeve van de aftiklijst zijn de volgende
communicatietrajecten doorlopen met:
• Het management van alle partijen ten be-
hoeve van het committeren aan de aftiklijst.
• De beheerorganisatie ten behoeve van het
gebruik van de aftiklijst.
• De ontwikkelorganisatie ten behoeve van het
verkrijgen van benodigde deliverables.
• De projectorganisatie ten behoeve van het
gebruik van de aftiklijst.
Tevens stelde men een maandrapportage (in-
clusief KPI’s vaststellen) op om de knelpunten
van de projecten te beschrijven, zodat het ma-
nagement geïnformeerd bleef over het verloop
van projecten.
Een belangrijk document inzake de gehele com-
municatie en interne en externe afstemming
tussen de verschillende afdelingen, bevatte de
werkafspraken. Hierin stonden zaken als: Wat
doet een projectboard? Waarvoor dient een pre-
kick-off? Waarvoor dient een kick-off? Hoe werkt
de beheeraftiklijst? Hoe loopt het escalatieproces?
Hoe dient de aftiklijst afgerond te worden? Hoe
moet er met het overdrachtsdocument ‘Inbeheer-
name’ omgegaan worden? Wat dient er tijdens
een evaluatie doorgenomen te worden?
Bij ieder onderwerp zijn de activiteiten en
verantwoordelijkheden van de verschillende
partijen (service-levelmanagers, beheerproject-
leider, projectleider, verantwoordelijken/actie-
houders) uitgewerkt.
TIP: Leg alle werkafspraken tussen de ver-
schillende afdelingen eenduidig vast in één
document.
Ad 3. Mensen
De beheerorganisatie was bij deze organisa-
tie enorm dynamisch (tegelijkertijd liepen de
reorganisatie van de business, van de beheer-
organisatie, de centralisatie van IT en outsour-
cing van IT). Hierdoor was het voor een (veelal
externe ) startende projectleider ondoenlijk in
zeer korte tijd te begrijpen wat er binnen de be-
heerorganisatie speelde. Daarom is er een pool
van zogenaamde beheerprojectleiders aange-
steld die ‘uitgeleend’ werden aan de projectlei-
ders, maar fysiek binnen de beheerorganisatie
acteerden. Zij vielen dus hiërarchisch onder de
beheerorganisatie, maar functioneel onder de
projectorganisatie. Doordat zij fysiek binnen de
beheerorganisatie acteerden, wisten zij wat er
binnen de afdeling speelde en konden zij anti-
ciperen waar een dienst binnen de (interne en/
of externe) beheerorganisatie moest landen.
TIP: Houd een beheerprojectleider binnen
elke afdeling wanneer de organisatie enorm in
beweging is. Wanneer de organisatie relatief
statisch is, kan overwogen worden de rollen
bij een centrale projectorganisatie te plaatsen.
Kritische succesfactoren
Terugkijkend op het gehele traject kunnen de
volgende succesfactoren worden onderkend:
1. Een voor alle partijen concrete beheeraftiklijst.
2. Het gebruik van de aftiklijst als harde eis
neerleggen.
3. Het realiseren van concrete quick wins. De
maandrapportage was bijvoorbeeld direct
zichtbaar voor het management.
4. Heldere afspraken met het management van
Project
DELIVERABLES
t.b.v. ontwikkeling
business
Ontwikkeling
(applicatiebe-
heer)
Business
(functioneel
beheer)
DELIVERABLES
t.b.v. beheer
ontwikkeling
Ontwikke-
lings-
overdrachts-
document
Beheer-
aftiklijst
Business-
overdrachts-
document
Business-
aftiklijst
Ontwikkel-
aftiklijst
Beheer-
overdrachts-
document
DELIVERABLES
t.b.v. beheer
business
Beheer
(technisch beheer)
Figuur 2. Stand van de samenwerking business, beheer, ontwikkeling, project.

4. o k t o b e r 2 0 1 0 27
de ontwikkelorganisatie inzake hetgeen er
door de ontwikkelorganisatie opgeleverd
dient te worden aan het project en dus aan de
beheerorganisatie. Denk hierbij aan tech-
nische ontwerpen, beheerhandleidingen,
systeemdocumentatie, et cetera.
5. Heldere werkafspraken vastleggen tussen de
leden van de ontwikkelorganisatie, projector-
ganisatie en beheerorganisatie.
6. Houd de actiehouders binnen de beheerorga-
nisatie: degene die er last van heeft wanneer
iets niet wordt gerealiseerd verantwoordelijk
maken dat het er komt.
7. Documentbeheer inrichten: centrale plaats
documenten inrichten.
8. Een belangrijke kritische succesfactor is de in-
terne bemensing van de beheerprojectleiders
geweest. Dit voorkomt veel inwerktijd bij de
projectorganisatie, hetgeen dus pleit voor een
gedeeltelijke decentrale projectorganisatie.
Om de aftiklijsten geaccepteerd te krijgen is
ook een aantal zachte elementen waarmee
rekening gehouden moet worden:
A. Betrek alle partijen bij het opstellen van de
aftiklijsten (gevolg: betrokkenheid waardoor
de lijst van iedereen wordt).
B. Laat het management er zich middels een
plenaire sessie aan confirmeren (gevolg:
managementsteun).
C. Communiceer direct dat over drie maanden
lessen worden getrokken en zullen worden
verwerkt in een nieuwe aftiklijst (gevolg:
bereidheid mee te werken).
D. Geef bij alle partijen een of meerdere pre-
sentaties over de werkwijze (gevolg: eerste
vragen beantwoorden en eerste sceptische
houding wegnemen).
E. Zorg voor sponsoren (op hoog niveau) bij de
ontwikkelorganisatie, beheerorganisatie én
projectorganisatie.
Het succes van de beheeraftiklijst is ook
afhankelijk van de inrichting van de project-
organisatie. Het zwaartepunt ligt hier bij een
sturingsmodel en een projectfasering. Je dient
minimaal concrete projectboards te definiëren
met voldoende mandaat om businesscases en
PID’s goed te keuren. Ook moet er een pro-
jectfasering bestaan. Denk hierbij bijvoorbeeld
aan Prince2 of een fasering als: Uitwerken
opdrachtfase, Realisatiefase, Implementatiefase
en Evaluatiefase.
Vervolg
De business en de ontwikkelorganisatie staan
nu voor dezelfde uitdaging. Ook zij zullen bij
de projectorganisatie aan moeten geven wat
zij van anderen nodig hebben en zelf moeten
realiseren om de dienst te kunnen gebruiken
en te realiseren (bouwen-testen, et cetera). In
2009 is de ontwikkelorganisatie ook gestart
met de uitwerking van de werkwijze. Hierdoor
krijgt de projectorganisatie op termijn vanuit
alle partijen helderheid bij wat zij moet doen
om vanuit alle partijen decharge te krijgen voor
een project. Uiteraard zullen deze afspraken
tussen business, ontwikkeling en beheer
moeten worden afgestemd, zodat de aftiklijsten
elkaar aanvullen en niet tegenspreken.
TIP: Realiseer per partij één aftiklijst en
integreer ze (indien wenselijk) op termijn. Dit
voorkomt eindeloze discussies bij de realisa-
tie van die ene aftiklijst.
Gedurende de implementatie kwam regelma-
tig het voorstel terug om in één keer voor alle
partijen één generieke aftiklijst te maken. Er
is bewust gekozen voor een gefaseerd model,
zodat iedere partij voor zichzelf kon vaststellen
wat zij wilde. Wanneer iedere partij eenmaal
helder heeft wat zij nodig heeft en moet leveren,
kan ervoor gekozen worden om alle aftiklijsten
tot één integrale aftiklijst te maken ten behoeve
van het gebruik, de ontwikkeling en de imple-
mentatie van nieuwe diensten. 
Herman Limburg (herman.limburg@logica.com)
is IT-managementconsultant bij Logica.
...belangrijker
nog: nieuwe
IT-dienstver-
lening werd
sneller en
met hogere
kwaliteit
opgeleverd.
Note:
Realisatie implementatie van de beheeraftiklijst
Ter realisatie van de beheeraftiklijst zijn de
volgende acties uitgevoerd:
1 Inventarisatie beheerpartijen.
2 Sponsorship bij de beheerpartijen creëren.
3 Inventarisatie activiteiten en de verwachte
output/deliverables per beheerpartij.
4 Vaststellen procedures. Denk hierbij aan
de escalatieprocedure, procedures ter
realisatie van sommige deliverables (AK
Analyse, UC realisatie, et cetera).
5 Conceptbeheeraftiklijst (inclusief inlei-
ding, sponsors, afkortingenlijst) door alle
beheerpartijen laten adopteren.
6 Definitief maken beheeraftiklijst (akkoord
hoger management).
Om de samenwerking tot een succes te
maken ligt het zwaartepunt bij de aftiklijsten
en de acceptatie daarvan. Wat kan er nu zoal
in een aftiklijst opgenomen worden:
• Uitleg.
• Activiteiten.
• Deliverables (inclusief verantwoordelijke
toeleveraar).
• Escalatieprocedure.
• Afkortingenlijst.
Ad Activiteiten:
Bij de activiteiten kunnen de volgende attribu-
ten worden gedefinieerd en beheerd:
• Projectfase.
• Activiteitnummering en korte omschrijving.
• Verantwoordelijke binnen de beheerorgani-
satie.
• In samenwerking met wie het gerealiseerd
dient te worden.
• Welke deliverables er uit de activiteit die-
nen te komen.
• Benodigde doorlooptijd van de activiteit,
zodat de projectleider dit mee kan nemen
in zijn/haar planning.
• De actiehouder (zorgt dat het gerealiseerd
wordt).
• Deadline.
• Status van de activiteit.
• Opmerkingen.
Ad Deliverables:
Bij de deliverables kunnen de volgende at-
tributen worden gedefinieerd en beheerd:
• Deliverablenaam, -nummer en korte om-
schrijving.
• Template auteur.
• Template verantwoordelijke.
• Opsteller van de deliverable.
Excel is hierbij een uitermate geschikte tool.
Iedereen kan ermee werken en het is eenvou-
dig te maken.