ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Transition-to-support - Hoezo over de schutting

•
•
Logica IT Management
Logica IT Management

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

1 of 4
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
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...
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.
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.

More Related Content

Transition-to-support - Hoezo over de schutting

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