Ik heb goede ervaringen met het inzetten van beheerders in IT projecten. Vaak wordt bij de opzet van een IT project vooral aan de functionaliteit gedacht die moet worden opgeleverd. En om de kans op het slagen van een project te verhogen, wordt de scope goed afgebakend. Maar weinig projecten houden er in hun plannen rekening mee dat de ontwikkelde systemen ook in beheer moeten worden genomen.
Vaak staat aan het eind van het project ergens de actie “In productie”, en dat is wat het project betreft de laatste stap. Systemen kunnen in een jaar ontwikkeld worden, maar blijven vaak (tientallen) jaren in productie staan. Al die tijd moeten ze beheerd worden. Er zijn verwachtingen over de performance, het maken van back-ups, uitwijk in geval van calamiteiten, het oplossen ven verstoringen, de kennis van de beheerders, enzovoort. Deze verwachtingen worden zelden vooraf gemanaged door het project.
Beheerders ervaren vaak dat systemen na oplevering “over de muur” worden gegooid, zonder dat ze invloed hebben kunnen uitoefenen op de inrichting van de systemen. Het is dan ook niet vreemd dat de beheerders vaak met de hakken in het zand gaan staan en problemen met het nieuwe systeem afschuiven op het (inmiddels afgesloten) project.
Ik pleit er dan ook voor om beheerders al vroeg in IT projecten te betrekken. Zij kunnen op bovengenoemde aspecten al in een vroeg stadium adviseren, ze kennen de productieomgeving en kunnen de impliciete verwachtingen van het project expliciet maken. Mijn ervaring is dat een project veel makkelijker wordt geaccepteerd en met minder problemen in productie gaat als de beheerders in het project hebben meegedraaid. Een nadeel is natuurlijk dat als de beheerders in projecten zitten, het gevaar bestaat dat het beheer van de bestaande systemen minder aandacht krijgt. Hier moet goed op geanticipeerd worden.
Dus “Projecten: Nodig eens een beheerder uit bij het projectoverleg!”
Beste Sjaak,Het betrekken van de juiste mensen met de juiste kennis kan zelfs nog een stap eerder: bij het (pre)sales traject, dus nog voor de implementatie.Verkopers weten vaak goed waar ze het over hebben, maar zijn ook erg gebrand op het antwoorden met ‘ja’, terwijl nog maar moet worden aangetoond of het (tehnisch en functioneel) haalbaar en/of uitvoerbaar is. System requirements vormen tegenwoordig vaak een belemmering met als resultaat een mooi verkochte oplossing, maar voorlopig nog niet uitvoerbaar denk aan SP2 voor W2003 of SQL2005. Uiteraard mag ook van de klant vanuit diverse invalshoeken van het bedrijf de nodige kennis worden verwacht bij het pre-sales traject. Hetzelfde geldt met functionaliteit, het werkt wel, maar niet zoals de klant/ eindgebruikers het hadden begrepen. De eerste stap is om pre-sales ook de implementatie uit te laten voeren of verantwoordelijk te maken voor de implementatie. Zij waren betrokken bij het voor traject en weten wat er is afgesproken en wat de klant verwacht.Bij het betrekken van de juiste mensen met de juiste kennis bij het implementatie traject is inderdaad de volgende stap het after sales traject (beheer na implementatie). Een goede overdracht is uiteraard onontkoombaar (waaronder training). Al ben ik benieuwd naar het percentage projecten waar overdracht ook daadwerkelijk gebeurt. Zoals je al aangaf, ‘het over de schutting gooien’ van een geïmplementeerd project gebeurt te gemakkelijk, wie let daar op? Een overdrachtsdocument dat moet worden ondertekend door de partijen kan daarbij helpen.Om after sales te betrekken bij de implementatie is goed, maar andersom is het natuurlijk ook mogelijk. Laat het pre-sales/implementatie team een gedeelte van de after-sales doen voor de klanten waar ze het project voor hebben uitgevoerd/ geïmplementeerd voor een vooraf vastgestelde periode en waarbij ze nauw samenwerken met de operationele beheerders. Plan review meetings om de uitvoering van het beheer te bespreken en om openstaande punten als actiepunten aan owners toe te kennen.
Beste Sjaak,Je noemt het “over de muur gooien” van de resultaten van een project. De vraag die hier naar mijn mening bijhoort is ‘wie die muur gebouwd heeft’. Met andere woorden: projecten worden vaak geconfronteerd met een onduidelijke of ontbrekende loketfunctie aan de beheerkant waar ze terecht kunnen voor een nette overdracht van de resultaten van hun project.Het is mijn ervaring dat dit spanningsveld niet zo zeer kan worden weggenomen, maar wel kan worden verkleind.Hiervoor begin je met een eenvoudige inventarisatie van noodzakelijke middelen, documentatie (handleidingen) en communicatie (incl. trainingen) die je als beheerorganisatie van een project vraagt. Geef iemand de verantwoordelijkheid EN bevoegdheid om aanspreekpunt te zijn voor projecten, en geef projecten formele en expliciete decharge zodra ze er met dit loket uit zijn gekomen. Afhankelijk van de organisatie levert dit binnen enkele maanden een merkbare versoepeling op van het in beheer nemen van projecten, waarmee je meteen invloed neemt op minder uitloop van projecten in tijd en geld.
Een collega van me heeft een toepasselijk motto: Bouw begint met beheer!
Meedraaien in projecten gaat mij niet ver genoeg. Ik pleit voor een verregaande integratie van de ontwikkelafdeling en de beheerafdeling in één organisatie, zoals in het Software Development & Maintenance Center. De voordelen hiervan overstijgen de nadelen. Het geeft schaalgrootte resulterend in efficiency en verbeterde productiviteit en leidt tot een lager kostenniveau als gevolg van minder overhead en communicatie- en overdrachtskosten. Zie ook mijn bijdrage “Ontwikkelaars komen van Mars, applicatiebeheerders van Venus” (21 december).
Natuurlijk zit er een kern van waarheid in de stelling van Paul. Maar naar mijn idee zijn er tal van voorbeelden te noemen waarbij andere keuzes wellicht beter zijn. Bij de business issues moet je functioneel beheer betrekken, maar dit geldt niet voor (generiek) applicatie en/of technisch beheer. Een ander voorbeeld: beheerder hebben dagelijkse activiteiten, zoals het uitvoeren van onderhoud en het oplossen van verstoringen. Wil je deze mensen vrij te maken voor project activiteiten dan levert dat vaak planningsproblemen voor het project, wat ten koste gaat van de kwaliteit van het resultaat. Van de uiteindelijke implementatiedatum wordt immers niet afgeweken, er wordt eerder wat tijd afgesnoept van test-activiteiten of functionaliteiten. Of wat te denken van oplossingen waarbij ik het beheer ga outsourcen en zo kan ik nog wel even doorgaan.Kortom: er zijn ook genoeg situaties te bedenken waarbij de waarde van het betrekken van beheerders geen effect heeft.
Het is makkelijk gezegd om beheerders mee te laten draaien in projecten. Het klinkt nog sympathiek ook. Het is echter wel een operationele oplossing voor een complexer probleem.Allereerst moet je afvragen waarom in projecten zo slecht wordt nagedacht over het beheer van de diensten en producten die ze opleveren. Vaak ontbreekt aan de start van het project al een goed inzicht in wat de beheer eisen zijn. Goede acceptatie criteria vanuit het beheer oogpunt zouden in deze fase al aanwezig moeten zijn. In de genoemde muur zou een deur moeten zitten die opengaat als aan deze acceptatiecriteria zijn voldaan.Verder zou het goed zijn als er meer sprake is van roulatie tussen de verschillende rollen, zodat niet alleen beheerders plek nemen in projecten maar ook ontwikkelaars beheerwerkzaamheden uit kunnen voeren. Het team model uit MOF (www.microsoft.com/mof)biedt hiervoor aanknopinspunten.Tot slot, beheerders kunnen een positieve bijdrage leveren aan projecten. Dan zullen beheerders ook echt aan projecten toegewezen moeten worden. Nu komt het nog vaak voor dat beheerders op escallaties moeten reageren en toch weer de operatie worden ingezogen. Beheerders mogen alleen meedoen met projecten als ze op dat moment opgeven beheerder te zijn.
De stelling dat beheer het stiefkindje van projecten is, is een dooddoener. Al vele jaren is men zich er in IT-land van bewust dat het leven niet ophoudt bij de “muur” en is men van mening dat beheerders moeten participeren in projectactiviteiten en -besturing. Waar het echter wel aan schort zijn de daden. De woorden zijn mooi, maar hoeveel gelegenheid krijgen / nemen beheerders om effectief een bijdrage te leveren aan deze trajecten? Waar ligt hun mandaat? En weten ze zelf eigenlijk wel wat de criteria zijn die ze (moeten) hanteren als het gaat om ontwerp- en implementatiecriteria van nieuwe systemen? Alleen de meest gekwalificeerde beheerders komen voor deze rol in aanmerking, en deze blijken vaak nodig te zijn voor de dagelijkse beheerbeslommeringen. Kortom, een mooie spagaat.
Om een adequaat (applicatie)beheer zeker te stellen is meer nodig dan alleen meedraaien in een project. Naast het inbrengen en opdoen van kennis door behereders is het essentieel dat het project aan diverse acceptatiecriteria voldoet. Deze gaan over afspraken, project, product, implementatie, proces en organisatie. Echter, veel beheerders vinden het lastig om deze op te stellen, waardoor de projectmedewerkers niet goed weten waaraan zij moet voldoen. Om hiervoor een oplossing te bieden, hebben bijna 180 beheerders uit diverse organisaties zich op een bijeenkomst van de ASL BiSL Foundation hierover gebogen. Zij hebben hun ervaring in een white paper vastgelegd, zie http://www.aslbislfoundation.org/nl/asl/fileadmin/web_documents/publications/asl_whitepaper_in_beheer_nemen_van_een_applicatie_nederlands_definitief.pdf.
Laat ik voorop stellen dat ik het vroegtijdig betrekken van beheer bij projecten een zeer goede eerste stap vind. Om concrete resultaten te behalen is het echter wel belangrijk de beheerder een opdracht mee te geven, ofwel helder te hebben welke eisen straks in de beheerfase aan de omgeving gesteld worden. Dit vraagt van service management / account management om al aan het begin van het traject met de business in gesprek te gaan over de eisen die straks aan de omgeving gesteld worden. Zowel in technische zin (beschikbaarheid & performance van de applicatie) als in functionele zin (hoe snel en hoe vaak zijn functionele wijzigingen nodig).