Al zolang projecten worden overgedragen naar beheer is er wrijving tussen beide organisaties; beheerders vinden stabiliteit en continuïteit belangrijk en projectleden richten zich op functionele verandering van informatiesystemen. Het project wil de deadline halen en beheer vreest dat zij de rommel mogen opruimen. Maar gelukkig komen er ook steeds meer verbeteringen in deze samenwerking. Best practices vanuit verschillende organisaties borrelen op welke bijdragen aan een soepele transitie van project naar beheer. Een aantal van deze best practices zijn in een workshop tijdens de ServiceManagerDag 2010 geïnventariseerd en staan hieronder beschreven.
Verschillende doelstellingen
Overdrachten van project naar beheer gaan moeizaam. De oorsprong hiervan zit hem in de doelstellingen die beide organisaties van nature hebben. Projecten hebben een korte termijn doelstelling die eindig is (product opleveren) en hebben de focus volledig gericht om de strikte projectdeadlines, waarbinnen alles dient te gebeuren, te halen. Aanvullende eisen die niet direct met dit doel te maken hebben, krijgen vaak minder prioriteit. Beheer wil stabiliteit; veranderingen mogen het liefst alleen doorgevoerd worden als onomstotelijk vaststaat dat de aanpassing geen verstoring heeft op de productomgeving. En gaat het mis, dan is de opmerking ‘told you so' een veelgehoorde kreet. Dit kan echter ook anders.
Verbeter de wereld, begin bij jezelf
Natuurlijk is het voor een beheerorganisatie gemakkelijk om met het vingertje naar een ander te wijzen, maar er kan ook veel verbeterd worden in de houding van de beheerorganisatie zelf. Zo heeft een grote verzekeringsorganisatie ervoor gekozen om de servicemanager aanvullend de rol van accountmanager te geven. In plaats van zich defensief op te stellen, werd er verwacht dat de servicemanager zelf acquisitie ging doen. Door de diensten van beheer (expertise) aan te bieden en dus te laten zien dat beheer toegevoegde waarde kan bieden, kreeg beheer meer invloed op de nieuw te ontwikkelen producten. Ook het imago van de beheerafdeling veranderde hierdoor, van reactief en contra-productief naar meewerkend en pro-actief.
In de workshop werd bevestigd dat bovenstaand niet alleen zo werkt in een profit-organisatie of één die met doorbelasting werkt, maar ook in overheidsorganisatie of een organisatie waar ict nog als stafafdeling wordt georganiseerd.
'You created this situation, you solve it'
Voor veel projecten houdt de projectfase op zodra het product is opgeleverd. Nazorg is of niet gebudgetteerd en/of niet opgenomen in de planning. Vanuit de beheerorganisatie dient een eis te komen dat alle projecten een nazorgfase hebben als onderdeel van het project. In deze nazorgfase gaan beheerders en projectleden gezamenlijk de openstaande punten na die van invloed kunnen zijn op de (in)stabiliteit van de productionele omgeving. Hierbij moet het project in de lead zijn. Na een periode van enkele weken wordt dit omgedraaid en is de beheerorganisatie in de lead. Doordat de projectorganisatie geconfronteerd wordt met de beheerproblematiek, wordt de bewustwording vergroot om zo de kwaliteit van de op te leveren producten (documentatie, beheersbaarheid) op het niveau van de beheerorganisatie (acceptatiecriteria) te laten komen.
Eerdere inzet van beheerders
Maar natuurlijk kan dit ook andersom. Door beheerders mee te laten draaien in projecten, wordt de acceptatiegraad onder de beheerders verhoogd. Zo kwam tijdens de workshop naar voren dat een logistieke organisatie 20 procent van de tijd van beheerders gealloceerd heeft voor het deelnemen aan projecten en tevens onderlinge kennisuitwisseling tussen de beheerders over deze projecten. In het begin leverde deze aanpak wel wat strubbelingen op. Doordat in de beginfase van een project de input van beheerders beperkt bleef tot het stellen van algemene eisen, leverde dat vragen op als 'Wat doe ik hier? Wat doet die beheerder hier, zit die alleen maar tijd (en dus projectbudget) op te maken?'. Hierop werd er een aanpassing doorgevoerd in de tijd die beheerders doorbrachten bij projecten. Naarmate het project vorderde werd de claim op tijd van beheerders verhoogd (tot maximaal de genoemde 20 procent). De acceptatiegraad van de beheerders (en die van de overige projectleden) werd verhoogd doordat zij nu een nuttige bijdrage hebben geleverd aan de resultaten van de projecten.
Begeleid de projecten I
Vaak komen projecten pas in beeld bij de beheerorganisatie zodra de implementatie in de buurt komt. Door alle projecten te laten vallen onder de governance van changemanagement worden ze direct zichtbaar. Aanvullend hierop dient het CAB (change advisory board) geïnformeerd te worden over wijzigingen op de scope van het project. Door deze zichtbaarheid van de projecten en de ontwikkeling van de scope tijdens het project, ontstaan er uiteindelijk minder verassingen. Hiermee wordt direct verankerd dat de eisen vanuit beheer meegenomen worden bij elke wijziging op de projectscope, die in het verleden vaak ten koste ging van de beheersbaarheid van het eindproduct.
Begeleid de projecten II
Projectorganisaties worden tijdelijk opgetuigd. Hierdoor gaat er kennis verloren en wordt het wiel vaak opnieuw uitgevonden. Aan de beheerkant is vaak geen tijd om in elk project voldoende en actief deel te nemen. Een overheidsinstelling heeft ervoor gekozen om een apart team in te zetten dat projecten begeleid. Het team bestaat uit (informatie en technisch) architecten en servicemanagers. Het team wordt aangevuld met beheerspecialisten uit de staande organisatie waar nodig. Het doel hiervan is om aan elk project een set van eisen vanuit de beheerorganisatie mee te geven. Met dit team worden de eisen ‘gebracht' waarmee de kans dat voldaan wordt aan deze acceptatiecriteria aanzienlijk groter wordt.
Het strategische belang
Voor alle in de workshop genoemde voorbeelden geldt dat het management gekozen heeft voor een aanpak waarbij ingezien wordt dat beheer toegevoegde waarde biedt. Er is zorg gedragen voor een verankering van beheeraspecten op strategisch niveau. De uitwerking waarin dit is gedaan, bleek minder relevant. Voorbeelden hiervan zijn het toewijzen van beheerresources, het onder governance van beheer brengen van projecten of zelfs compleet aparte transitieorganisaties inrichten. Allen waren succesvol omdat het management van mening is dat het goed beheren van informatiesystemen van cruciaal belang is voor de continuïteit van de organisatie, en deze methoden dragen hieraan bij. Nog belangrijker dan het draaien van projecten in het kader van vernieuwing en innovatie.
Conclusies
Ondanks dat procesmodellen in vele vormen beschikbaar zijn, blijkt toch communicatie en aandacht het meest cruciaal te zijn. Daarnaast is de verankering van het belang van beheer op strategisch niveau fundamenteel. Op dat niveau wordt dan geborgd dat er niet alleen oog is voor innovatie (in projecten) maar zeker ook voor de kracht van stabiele informatiesystemen in productie. De modellen die noodzakelijk zijn om governance op je beheersituatie uit te voeren (BiSL, ITL, ASL) zijn heel belangrijk en moeten zeker aanwezig zijn, maar zijn niet meer dan commodity geworden. De organisatorische borging van beheer moet daar bovenop de echte toegevoegde waarde gaan brengen.
Dit artikel is geschreven door Patrick Mingaars en Jeroen Bekaert
Bovenstaande is een interessante aanzet tot noodzakelijk en fundamenteel anders denken vanuit een beheerorganisatie. Beheer en business (en Informatie management) zijn namelijk samen verantwoordelijk om de dynamiek van de branche waarin zij succesvol moeten zijn te adapteren in hun organisatie. En ICT dient te anticiperen om dit in haar organisatie te realiseren.
Beheersbaarheid en stabiliteit zijn achterhaalde pijlers, waarachter een beheerorganisatie zich niet langer kan verschuilen. Inspelen op innovaties, flexibiliteit en een veranderde omgeving zijn inherent aan de huidige manier om de business werkelijk te laten profiteren van de mogelijkheden van ICT. Eerstgenoemde zijn randvoorwaardelijk, als een rem om verantwoord te kunnen autorijden.
Als het ITIL Change management proces werkelijk een best practise ambieert te zijn dan is het reactief accepteren van een grootschalige wijziging in de beheerorganisatie een naïeve wijze van meerwaarde proberen te leveren voor de business. Projecten hebben een hoge (business) management attentie in de vorm van stuurgroepen, het accepteren van behaalde mijlpalen en het inhuren van hoogwaardige resources, extern of vanuit de beheerorganisatie. Terwijl de ICT projectenorganisatie op volle toeren draait, vertrouwt de ICT-organisatie op haar acceptatiecriteria in het CAB.
Legio zijn de voorbeelden waar, onder druk, de wijziging alsnog geaccepteerd wordt (moet worden) door de ICT-organisatie. Het gaat niet het probleem van de ICT-organisatie worden, het is het al.
Lang hebben we verteld wat goed is voor de business. Om weer mee te mogen doen, hebben wij ons getransformeerd tot een business enabler. We staan niet langer reflexmatig op de rem, alleen moeten we nu nog leren hoe we onze handen ook op het stuur krijgen.
Dit is een terechte zorg. Er gaat op dit vlak inderdaad het nodige mis.
In de nieuwe versie van PRINCE2 wordt duidelijk gemaakt dat beheer meestal moet worden gezien als een van de toekomstige gebruikers van het project. Beheer dient daarmee ook kaliteitsverwachtingen te specificeren en testen uit te voeren voor acceptatie.
Geen Governance graag, zoals hierboven wordt gesuggereerd. Er lopen al genoeg projecten fout door te veel focus op de techniek en te weinig focus op de business/gebruiker.
Over de visie dat (en hoe) Beheer moet worden gezien als toekomstige gebruiker heb ik al ruim voor de 2009 versie van PRINCE2 een document geschreven. Dit is te vinden in mijn LinkedIn profiel.
Ik kan dit ook per email versturen. Stuur mij daarvoor een verzoek naar nico@viergever.info