Case Study: Wat maakt dat de ene ECD/ EPD implementatie succesvoller is dan de andere?

Iedereen die meerdere keren betrokken is geweest bij een ECD of EPD implementatie heeft zich wel eens afgevraagd waarom de implementatie bij de ene zorginstelling beter gaat dan bij de andere. En dat terwijl de organisaties vaak in grote mate op elkaar lijken en het veelal gaat om een standaard, bewezen oplossing. Door de oogharen bekeken: 80% is hetzelfde. Zorginstellingen zitten in grote mate op dezelfde manier in elkaar als het gaat om structuur, processen, functies, financiering, etc. Natuurlijk zijn er ook verschillen zoals tussen de verschillende zorgvormen, financieringen, omvang, terminologie en cultuur. Maar is er ook heel veel hetzelfde. Waarom is de ene implementatie van een ECD/ EPD (voor de leesbaarheid gebruik ik verder ECD) dan succesvoller dan de andere? Daar is al veel over geschreven, wat gaat deze blog daar nog aan toevoegen?

De afgelopen periode heb ik als projectleider twee implementaties mogen begeleiden van hetzelfde ECD. Eén als projectleider van de leverancier en bij de andere was ik projectleider aan de kant van de klant. Beide organisaties waren enigszins vergelijkbaar: groot qua omvang, zelfde vormen van zorg en financiering: jeugdzorg in dit geval. De projecten liepen parallel en zijn beide op tijd en binnen budget opgeleverd. En beide organisaties hadden helaas ook een eerdere implementatie achter de rug die niet succesvol was. Wat waren de overeenkomsten tussen deze twee projecten waardoor ze succesvol zijn geëindigd

Een ervaring die mij nieuwe inzichten heeft gegeven over wat wel en niet kan bijdragen aan een succesvolle implementatie. De moeite waard om te delen.

Zoals geschetst leken beide organisaties op elkaar. Beide groot en complex, maar de één was nog weer groter dan de ander. Beide leveren jeugdzorg maar daarbinnen zaten wel verschillen in het portfolio. Ook qua cultuur, organisatiestructuur, volwassenheid en governance zaten er duidelijke verschillen. Vier aspecten met verschillen waar vaak juist cruciale randvoorwaarden aan worden gesteld om een succesvol project te draaien.

Genoeg verschillen dus om een ander eindresultaat te verwachten. In de aanpak van het project zaten echter een aantal overeenkomsten waarvan bij de evaluatie is vastgesteld dat die cruciaal zijn geweest voor het welslagen van deze projecten:

1. Er waren hele duidelijke leidende principes in het project waar de aanpak en besluitvorming langs gelegd konden worden.
2. Het projectteam was dedicated, vrijgemaakt voor het project en was compact.
3. De go-live datum kon niet worden uitgesteld. Dat was absoluut geen optie.
4. De implementatieproject en het verandertraject (borging) in de organisatie waren losgekoppeld van elkaar.

Op deze vier punten ga ik hieronder verder duiden.

Duidelijke leidende principes

In beide projecten waren hele scherpe leidende principes vastgelegd. Denk aan een best-practice inrichting, aanpak van de leverancier als leidend, geen maatwerk, implementeer as is en ga niet direct ook optimaliseren. Afwijken van de best-practice kan alleen na akkoord van de stuurgroep, mandaat bij het projectteam, etc. Op basis van deze leidende principes konden veel discussies en keuzes in het project snel worden beslecht en was het ook niet nodig deze met de achterban, de organisatie, te bespreken. Deze aanpak zorgde voor meer slagvaardigheid in het project en zorgde daarmee voor een hoog tempo. Alleen bij uitzondering moest er een besluit genomen worden door de stuurgroep of moest een klankbordgroep geraadpleegd worden. Het tempo wat gerealiseerd werd hierdoor zorgde dat het deadlines gehaald werden en de aanpak gaf het projectteam ook het comfort om de keuzes te maken.

Daarnaast hielpen de leidende principes ook om de ambities realistisch te houden. Het is de natuurlijke neiging om vanuit het project het nieuwe ECD zo optimaal mogelijk neer te zetten en daarmee meer te doen dan gevraagd wordt en alle toeters en bellen van de applicatie te implementeren. Daarbij wordt soms uit het oog verloren dat de overgang naar een nieuw ECD al een hele grote verandering is voor de organisatie. Als je dan ook nog allerlei stappen gaat optimaliseren, automatiseren of veranderen loop je aan tegen de grenzen van de verandercapaciteit van de organisatie.

Zorg eerst voor de basis op orde, dat is al een hele grote stap. Maar definieer ook op voorhand al een fase 2 om wel die optimalisaties te gaan realiseren. Enerzijds zijn die nodig en bieden als het goed is meerwaarde maar creëert ook hier comfort bij het projectteam om zaken te parkeren naar een volgende fase. Als er geen perspectief is op een fase 2 is men al snel bang dat een verbeteroptie nooit gerealiseerd gaat worden. Voordeel van een fase 2 voor de optimalisaties, is ook dat de praktijkervaring met het nieuwe ECD mee kan worden genomen, wat uiteindelijk zorgt voor veel betere optimalisaties dan wat theoretisch tijdens een eerste implementatie kon worden bedacht.

Dedicated projectteam

De bemensing van een dergelijk project is vaak erg lastig, zeker met de personeelstekorten die er zijn. Om toch een brede representatie van de organisatie te krijgen wordt er een vrij omvangrijk projectteam met werkgroepen opgezet. Consequentie is dat veel mensen een beetje met het project bezig zijn. Dat gaat ten koste van de focus op wat er moet gebeuren voor het project. En heel praktisch, zaken als het plannen van afspraken is een crime en dus tijdrovend en vertragend. Ten slotte geeft een brede representatie ook meer ruimte voor uitvoerige discussies over wat de beste oplossing zou moeten worden. Hoewel die discussies goed zijn voor het draagvlak van de uiteindelijk gekozen oplossing, is de meerwaarde voor de kwaliteit van de implementatie beperkt. Het gaat namelijk niet om discussies over of iets wel of niet goed is, maar vooral welke oplossingsrichting beter is: goed, beter, best. En vaak komt er ook nog een stukje strijd bij vanuit het verleden omdat veel organisaties vanuit diverse fusies en overnames zijn gegroeid of vermeende verschillen in zorgvormen. Tijdrovende discussies die de voortgang in de weg staan, zonder dat ze dus een wezenlijke bijdrage leveren aan de kwaliteit van de implementatie.

In beide projecten is juist gekozen voor een compacter team wat (bijna volledig) vrij gemaakt was voor het project, met een beperkte representatie vanuit de organisatie. Maar met de leidende principes onder de arm, bleek dit veel slagvaardiger. Er was focus en de samenwerking in het project kon goed georganiseerd worden. Niet onbelangrijk want je moet het met elkaar doen. De rolverdeling was helderder, wat voor de projectleden meer duidelijkheid gaf over waar ze verantwoordelijk voor zijn: dus beter in staat hun rol uit te voeren en wist ze waar ze aanspreekbaar op waren. En gegeven de druk die altijd op dit soort projecten zit, hadden ze daarmee al genoeg aan hun hoofd.

Wel is het belangrijk om contact met de organisatie te realiseren: immers niet alle kennis is beschikbaar in het projectteam en draagvlak voor gemaakte keuzes moet georganiseerd worden. Afhankelijk van de aard van de beslissing kan dat bij de stuurgroep liggen. Maar op detailniveau of als er inhoudelijke kennis nodig is, is de stuurgroep niet altijd het juiste gremium. Het inrichten van klankbordgroepen waar bijvoorbeeld wekelijks in een uur de belangrijkste punten worden besproken bleek een goede werkwijze te zijn voor die besluiten waar de kennis ontbreekt en te toetsen of bepaalde gemaakte keuzes juist waren. Het projectteam kreeg comfort bij de gemaakte keuzes. De inhoudelijk toetsing borgde dat de kwaliteit en motivatie van de keuzes ook helder naar de organisatie gecommuniceerd konden worden. Het was helder waarom de zaken gedaan waren zoals ze gedaan waren. Goede documentatie hierbij is cruciaal zodat de onderbouwing begrijpelijk blijft.

Geen uitstel mogelijk

Grofweg zijn er 3 knoppen waar je in een project aan kan draaien: kwaliteit, capaciteit en tijd. Op het moment dat het spannend wordt in een project komt de onvermijdelijke vraag: aan welke van die knoppen ga je draaien? Het projectteam wil een zo goed mogelijk project opleveren. Door middel van een draai aan de kwaliteitsknop daar concessies aan doen, voelt als falen. Meer capaciteit is ook vaak om meerdere reden niet haalbaar. Als er al meer capaciteit beschikbaar te maken is, is het de vraag wat het daadwerkelijk toevoegt aan extra snelheid. Extra projectleden moeten ingewerkt worden en het projectteam dijt uit met extra of langere overleggen tot gevolg. Het bestaande projectteam harder laten werken is ook niet reëel: de werkdruk is daar vaak al maximaal gestretcht.

Op zo’n moment komt uitstel van live-gang in beeld. Mijn ervaring is dat er dan een boeiend fenomeen optreedt: doordat er uitstel mogelijk is, wordt enerzijds de tijdknop naar achter gedraaid maar vaak ook de kwaliteitsknop omhoog. We stellen wel uit maar er moet wel meer gerealiseerd worden. Hierboven heb ik al uiteengezet dat het verhogen van de kwaliteit veel tijd kost, er moeten immers ingewikkelde discussies worden gevoerd en beslecht over wat de beste oplossing is. Het resultaat: wel een latere deadline, veel extra kosten en maar beperkt betere, kwaliteit. Iets wat je veel efficiënter kunt realiseren in een optimalisatie fase waarbij je een stuk praktijkervaring meeneemt.

In een scenario waar geen uitstel mogelijk is, blijft dus eigenlijk alleen het draaien aan de kwaliteitsknop over. En nee, dan hebben we het niet over het zover naar beneden draaien dat je op een ‘onvoldoende’ komt of met de hakken over de sloot. Het is het open gesprek over wat verwachten we als projectteam versus wat verwacht de organisatie. Dan blijkt dat de lat van het projectteam vaak hoger ligt dan de opdrachtgever verwacht en mogelijk ook wat de organisatie aan kan. Wat moet nu, wat kan ook later? Ik heb zoveel live-gangen gezien waarbij allerlei gerealiseerde functionaliteiten niet gebruikt werden of bepaalde optimalisatie al snel na het gebruik teruggedraaid werden. Op het moment dat je die punten duidelijk met elkaar durft te benoemen en te parkeren, creëer je lucht in het project. In die discussie hielp het sterk als de tijdsknop vaststaat. Dat bewustzijn bij het projectteam zorgde voor focus.

De daadwerkelijk verandering en borging vindt pas na het project plaats

Het ‘technisch’ neerzetten van een ECD is één, maar zorgen dat het gebruikt gaat worden zoals het is bedoeld, is twee. Veel aandacht in een project gaat uit naar communicatie en opleiding om te bewerkstellen dat de organisatie het ECD goed gaat gebruiken. Deze veranderopdracht ligt vaak ook bij het projectteam. Maar is het wel realistisch dat een projectteam van slechts enkele tientallen mensen verantwoordelijk kan zijn voor de veranderingen diep op de werkvloer bij honderden of duizenden mensen?

Natuurlijk kun je met opleiden en communicatie veel doen. Ook een servicedesk, applicatiebeheer, key-users, ECD-coaches, etc. kunnen allemaal een rol spelen. Naar mijn mening echter is primair het lijnmanagement verantwoordelijk voor de borging binnen de teams. Zij hebben de hiërarchische verantwoordelijkheid en kennen hun mensen. Bij veel ECD-implementaties gaat er te weinig aandacht uit naar de rol die operationeel managers in deze verandering moeten hebben. Juist naar deze groep medewerkers moet veel opleiding en communicatie gaan en ook zij moeten actief het ECD gaan gebruiken. Zij moeten uitgerust worden met de juiste instrumenten om in hun teams het ECD succesvol te gaan gebruiken. En dat is een traject wat niet alleen tijdens de implementatie speelt, maar vooral juist daarna. In de ‘nazorgfase’ moet veel meer aandacht gaan naar het voeden en ondersteunen van de operationeel managers zodat zij hun teams op de juiste wijze met het ECD laten werken, in plaats van dat ‘af te schuiven’ op het project of support/applicatiebeheer.

Mijn advies is om in de projectaanpak dit heel duidelijk een plaats te geven. Dat expliciet maken, zorgt bij de start van het project al voor een discussie: “oh maar dat moeten jullie als project toch doen”. Vanaf dat moment het bewustzijn creëren dat lijnmanagement hier aan zet is in plaats van het project zorgt voor een goede voorbereiding. Na live-gang is er dan nog een substantiële fase nodig om de lijnmanagers te ondersteunen bij het borgen in de organisatie met tools en kennis gestoeld op de praktijk.

Mijn advies is om in de projectaanpak dit heel duidelijk een plaats te geven. Dat expliciet maken, zorgt bij de start van het project al voor een discussie: “oh maar dat moeten jullie als project toch doen”. Vanaf dat moment het bewustzijn creëren dat lijnmanagement hier aan zet is in plaats van het project zorgt voor een goede voorbereiding. Na live-gang is er dan nog een substantiële fase nodig om de lijnmanagers te ondersteunen bij het borgen in de organisatie met tools en kennis gestoeld op de praktijk.

Waren er meer aspecten die mee hebben geholpen? Ongetwijfeld. Zo weet ik niet of het gunstig is geweest dat er sprake was van een eerdere mislukte implementatie van een ECD. Wordt men daar kritischer van? Of luistert men juist beter naar de leverancier die vaker een ECD implementatie heeft gedaan? Beide organisaties kenmerkten zich door een goede zelfreflectie op hun eigen rol bij de vorige implementaties. Die volwassenheid heeft mogelijk ook een rol gespeeld.