Het is onvermijdelijk, maar wel wenselijk: elk project levert een keer haar producten op (er van uitgaande dat het project niet voortijdig is gestopt). Dagen, weken, maanden is er hard gewerkt om allerlei producten op te leveren. En dan is het moment daar: tijd om de producten ook te gaan gebruiken. We gaan live! We leveren de producten af aan de opdrachtgever en dan zijn we klaar, toch?
Niet dus. Live gaan (G0-Live) met je producten is een precair proces dat naar mijn mening te vaak te weinig aandacht krijgt. In de regel managen we go-live’s gewoon via de standaard project stuurmiddelen die voor handen zijn: tijd, geld, kwaliteit en scope. Maar als je nou werkelijk naar de Go-Live kijkt, gelden deze stuurmiddelen dan nog wel? Is de tijd om de producten te creëren niet al verstreken (je gaat tenslotte live)? Is het budget niet allang vastgesteld, bewaakt en enige overschrijding reeds geaccordeerd (je gaat tenslotte live)? En is de kwaliteit niet allang vastgesteld en goed gekeurd (je gaat tenslotte live)? En de scope? Als er nog discussie ontstaat over de scope bij een Go-Live, dan is er iets goed mis in je project.
We gaan dus andere middelen van stal halen. Er worden boeken volgeschreven die moeten dienen als draaiboeken. We volgen gewoon het draaiboek en dan gaat het wel goed. Maar oh jee, de bekende Murphey komt voorbij. Het gaat dus niet goed. Paniek! Crisis-mode wordt aangezet en we redden wat er nog te redden valt. Bovendien lopen er allerlei mensen rond die allerlei moeilijke vragen gaan stellen. En terecht, want die mensen betalen tenslotte voor het project en willen dus ook weten hoe een en ander verloopt. Maar dat kost wel tijd en tijd hebben we niet. Bovendien bemoeien ze zich overal mee en dat kan je dan juist helemaal niet hebben.
Aandacht
Hadden we nou maar …. eerder aandacht besteed aan de vraag hoe we live moeten gaan.
Hoewel bovenstaande beschrijving nogal simpel van aard is, denk ik wel dat het heel herkenbaar is voor velen. In het voortraject besteden we veel aandacht aan de inhoud van de op te leveren producten. We stellen requirements op, we testen deze uitvoerig en op een gegeven moment accepteren we de kwaliteit van het product. 'We kunnen live' is dan de conclusie.
We besteden nauwelijks tot geen aandacht aan het proces om live te gaan. Althans, niet meer dan ook weer de, wat ik noem, technische voorwaarden. Wat moet ik doen, welke acties moet ik uitvoeren? Het zogenaamde draaiboek. Maar de vraag hoe je om wilt gaan met issues die ontstaan is net zo belangrijk. Als je niet in staat bent issues tijdig te onderkennen en te managen kan dat een nogal negatieve impact hebben op je Go-Live. Te vaak is dat een reden voor een NoGo, terwijl dat wellicht niet had gehoeven als je niet in crisis-mode had gezeten.
Die mensen die rondlopen op de werkvloer en allerlei vragen stellen, willen ook graag op de hoogte gehouden worden. Ad hoc informeren kost te veel tijd, daarom willen we ze eigenlijk niet op de werkvloer hebben.
Een goede Go-Live vraagt voorbereiding. Voorbereiding die al lang voor de Go-Live datum begint. De Go-live processen moeten voorbereid worden. Ook deze moeten getoetst en getest worden. En uiteindelijk wordt de Go-Live pas echt succesvol als je in staat bent dit met grip en controle uit te voeren.
In mijn beleving dienen de volgende onderdelen al vroegtijdig aandacht te krijgen:
– Planning
– Mandaat en Informatieverschaffing
– Issue management
Bij Planning worden de welbekende draaiboeken opgeleverd. Maar er is meer. Bij een Go-Live spelen vaak meerdere partijen een rol, grofweg onder te verdelen in Uitvoerende partijen en Controlerende partijen. Zijn deze partijen wel goed op elkaar afgestemd? Als er iets wordt verwacht, bijvoorbeeld een rapportage, wordt deze ook wel echt geleverd conform het draaiboek? Afstemming is dus cruciaal bij het opstellen van het draaiboek. Daarnaast dient een Go-Live vaak plaats te vinden binnen een vooraf gestelde tijd. De afstemming richt zich ook op de vraag of de hele Go-Live wel haalbaar is binnen deze tijd. Dat is iets wat je liever al vroegtijdig weet zodat je het kunt bediscussiëren met je stuurgroep. Wellicht vormt het zelfs een requirement voor de op te leveren projectproducten en scenario's.
Bij Mandaat en Informatieverschaffing moet worden gekeken wie nou werkelijk het mandaat heeft om tijdens een Go-Live beslissingen te mogen nemen. Vaak zie je bij Go-Live's dat er andere mensen betrokken zijn in de stuurgroep dan tijdens de voorbereidingen. En de volgende vraag dient zich ook aan: hoe hou je deze mensen, bij voorkeur actief, op de hoogte van de voortgang, zonder dat zij zelf op de werkvloer gaan rondlopen en mensen van hun werk houden? Of in het ergste geval: zich overal mee gaan bemoeien? Informatieverschaffing, zowel qua inhoud als qua format is dus net zo belangrijk om al je stakeholders goed en tijdig op de hoogte te brengen en te houden. Dat vraagt voorbereiding en afstemming.
Als laatste het punt van Issue management. Ik noem dit bewust issue management en niet incident- of problem management of iets dergelijke. Een issue dat zich voordoet hoeft niet noodzakelijkerwijs een probleem te vormen. Het kan ook geaccepteerd worden. Er moet wel voorkomen worden dat een issue een probleem wordt.
Een issue moet goed gemanaged worden. Als het dan toch een probleem wordt, moet het proces om tot de oplossing te komen bij iedereen bekent zijn, op voorhand. Anders ontstaat het welbekende kip-zonder-kop proces, resulterend in een NoGo, omdat de grip en controle is verloren of dreigt te worden verloren.
Bovenstaande onderdelen moeten tijdig worden voorbereid. Onderdeel van deze voorbereiding is ook de toetsing. De Go-live kan alleen succesvol zijn als bovenstaande onderdelen tezamen met het inhoudelijk werk één geheel vormen. En dat kan alleen bereikt worden (en gevalideerd) door de Go-Live ook vroegtijdig te toetsen. In een testomgeving. Kloppen de draaiboeken? Staat alles erin? Laat ik niets aan het toeval over? Ben ik in staat issues goed te managen? Krijgen mijn stakeholders de informatie die ze nodig hebben? Vormen al deze aspecten daadwerkelijk één geheel? Ben ik in staat grip en controle te hebben en te behouden op het totale proces?
Al met al komt er dus bij de voorbereiding meer kijken, dan slechts het doen. Dus geef de Go-Live niet als laatste aandacht, maar begin er vroeg mee. Misschien wel als eerste.
Herkenbare problemen! Het gaat mis bij live gaan, en achteraf blijkt dat je het (vaak eenvoudig) had kunnen voorkomen. Een goede voorbereiding is het halve werk.
Mijn ervaring is dat het betrekken van bv. systeem testers en maintenance engineers in een vroeg stadium bij de productontwikkeling veel oplevert. Deze professionals kijken met een andere bril naar het product, zoals installatie en onderhoud. En ook vanuit de klant, hoe gaat die het systeem gebruiken, wat verwacht de klant dat mogelijk is? Voor de systeemtester heeft het als voordeel dat hij zich beter kan voorbereiden voor het testen, en kan zien wat er door het ontwikkelteam al getest wordt. Dat voorkomt overlap in het testen, en spaart tijd en geld. De maintenance engineer bouwt kennis op van het product, en kan daarmee betere ondersteuning doen als er live problemen optreden. Kortom, een win-win voor alle betrokken, samenwerken loont!
Herkenbaar. Het is de ‘A’ in SMART.
Naast zaken als risicomanagement, opdrachtgeverschap en testen één van de faalfactoren – en *dus* succesfactoren – van een project. Inmiddels krijgt dit in het kader van ‘acceptatiemanagement’ gelukkig meer aandacht.
Het slagen van een project wordt aanzienlijk vergroot indien deze 4 aandachtsgebieden al vóór en gedurende de project startup meer of minder grondig in beeld worden gebracht.