Als een Continuous Improvement (CI)-programma op de juiste manier wordt opgezet, biedt het veel voordelen en substantiële waarde. Het creëren van een multidisciplinair team voor het opzetten van zo’n programma brengt echter de nodige uitdagingen met zich. Zo moet dit team soepel functioneren binnen jouw organisatie en waar nodig samenwerken met andere teams. Gelukkig zijn er richtlijnen die je kunt volgen voor het succesvol opzetten van jouw CI-programma.
Richtlijnen
1. Respecteer elkaars planning
Wanneer je de resultaten van alle teamleden wilt maximaliseren, moet je bij gezamenlijke vergaderingen aanwezig zijn. Deze kunnen iedere cyclus plaatsvinden met het volledige team, maar ook met slechts een beperkt aantal mensen die zich met een specifieke taak bezighouden.
Een uitdaging bij deze aanpak is dat nagenoeg alle teamleden hun tijd niet volledig kunnen besteden aan het team, iets waarop de product owner en data-analist wellicht een uitzondering zijn. Betrokkenen hebben dan ook naast hun verantwoordelijkheden binnen het team ook andere verantwoordelijkheden.
Zorg daarom dat alle teamleden CI-vergaderingen en -mijlpalen als prioriteit zien. Is dat niet het geval, dan loop je het risico dat het teamgevoel en de motivatie van individuele teamleden afneemt. Het correct prioriteren van vergaderingen is hierbij van groot belang, zowel voor interne als externe teamleden. Niet alleen zorg je zo dat alle benodigde expertises bij de vergadering aanwezig zijn, ook zorg je dat iedereen productief en scherp blijft.
2. Besluitvorming en planning
Het team en zeker de product owner moeten over de autoriteit en vaardigheden beschikken voor het stellen van prioriteiten. In sommige gevallen kunnen prioriteiten van teamleden echter met elkaar botsen. Het kan dan ook zijn dat je hierover moet onderhandelen. Het verkrijgen van een tijdsbudget vanuit het management dat het team aan het project mag besteden kan hierbij een goed startpunt vormen. Denk hierbij aan een vastgesteld aantal ontwikkeluren die maandelijks aan de backend mag worden besteed.
3. Doelen bepalen en resultaten meten
Een dergelijk programma brengt uiteraard verwachtingen en verplichtingen met zich mee. In tegenstelling tot projecten met een vaste einddatum en bereik, moet het team bij een CI-project hun doelen en resultaten inzichtelijk en kwantificeerbaar maken. De meeste betrokkenen hebben echter naast hun werk voor het team ook andere prioriteiten.
Zijn resultaten van het CI-proces onvoldoende inzichtelijk, dan kan dit ertoe leiden dat teamleden hun aandacht naar andere prioriteiten verschuiven. Levert het initiatief echter goede resultaten op en is het belang van het CI-proces duidelijk? Dan kan dit juist een positieve werking hebben. Zo kan dit onderhandelingen over prioriteiten en additionele resources vereenvoudigen, waarmee je de waarde vergroot die het CI-team oplevert.
Een manier waarop je het inzicht in en de focus op het CI-project kunt vergroten is het selecteren van een specifiek thema per kwartaal. Denk hierbij aan het vergroten van het verkeer of aan het verbeteren van de conversie.
4. Deel successen
In een CI-project met een breed bereik kan iedereen suggesties voor verbeteringen aanleveren en eindgebruiker zijn van het resultaat dat het team oplevert. Teamleden moeten zich bewust zijn van hun rol als ambassadeur en tijd reserveren voor het bespreken van het project met collega’s. Je kent vast situaties waar het management om een bepaalde oplossing vroeg en vervolgens geen aandacht had voor feedback hierop. Een dergelijke aanpak kan demoraliserend werken.
Dat wil overigens niet zeggen dat je voorstellen en plannen niet kunt uitstellen, zolang je hierover maar transparant ben. Zorg dat iedereen het proces begrijpt en kan achterhalen waarom bepaalde initiatieven niet de gewenste prioriteit hebben gekregen. Je kunt hiervoor allerlei tools inzetten, zoals een dashboard, een intranet of een projectboard. Teamleden moeten echter ook uitleg kunnen geven over de redenering achter bepaalde prioriteiten. Zorg daarom dat teamleden weten dat hun suggesties die niet direct worden opgepakt niet zijn afgekeurd en op een later moment alsnog opgepakt kunnen worden. Zeker de product owner moet het informeren van belanghebbenden over resultaten en de redenering achter prioriteiten als belangrijke taak zien.
5. Doelgedreven, kritiek en constructief
In multidisciplinaire teams met veel verschillende expertises kan de manier van werken afwijken van wat mensen gewend zijn. Het team moet zichzelf doelen stellen en teamleden moeten elkaar continu herinneren aan de waarde die hun project oplevert voor de business.
Dit vraagt om een positieve werksfeer op basis van constructieve feedback. Werken in een multidisciplinaire team kan in het begin raar aanvoelen, zeker als het gaat om communicatie tussen verschillende afdelingen of interne en externe teamleden. Belangrijk hierbij is dat je subjectiviteit in de discussie wegneemt en voorkomt dat discussiepunten persoonlijk worden. De scorekaart die je ook gebruikt in de Pain & Gain-analyse of het maandelijkse thema van het CI-project kunnen hierbij helpen. Zo moeten teamleden een ontwerper die een productpagina opnieuw ontwerpt kunnen vragen hoe de veranderingen de conversie gaan vergroten.
Hoe ga je aan de slag?
Ambitie
Een CI-project vereist allereerst motivatie. Voelt jouw organisatie daadwerkelijk de noodzaak voor het doorvoeren van verbeteringen? Zo vraagt een CI-project om:
- het afbreken van silo’s en het geven van de vrije hand aan mensen uit verschillende disciplines en van diverse afdelingen voor het in kaart brengen en verhelpen van de belangrijkste problemen;
- een CI-team dat prioriteiten kan stellen en de juiste mensen op de juiste moment kan toewijzen;
- feedback van klanten en werknemers op basis waarvan je daadwerkelijk handelt.
Ben jij klaar voor het ondersteunen van een multidisciplinair team en het verbeteren van de organisatie vanaf de onderzijde?
Bereik
Het selecteren van de juiste mensen en reserveren van resources is eenvoudiger wanneer je een beeld hebt van het bereik van het project. Ga je met een CI-project aan de slag, dan leg je bij voorkeur de focus op een specifiek gebied. Zo krijg je een goed gevoel voor wat werkt en hoe het proces kan worden verbeterd. Het boeken van vroegtijdige succes kan een belangrijke bijdrage leveren aan de omarming van CI in de organisatie. Kies je eerste stappen dus zorgvuldig.
Een goed startpunt voor het bepalen van het bereik is een algemeen onderzoek onder klanten en werknemers. Leg in dit onderzoek de focus op vragen over mogelijke verbeteringen voor klanten (je kunt ook werknemers hiernaar vragen) of vraag naar algehele potentiële verbeteringen, zowel intern als extern. Op basis van deze input bepaal je met welke verbeteringen je het best kunt beginnen. Bij voorkeur gaat het hierbij om echte problemen, die met beperkte middelen en in korte tijd verholpen kunnen worden.
Proces
Start met het definiëren van de eerste versie van het proces. Blijf deze eerste versie continu aanpassen en verbeteren. Belangrijke aandachtspunten hierbij zijn:
- Het tijdspad van een cyclus (dit is afhankelijk van de focus van de cyclus en beschikbare middelen. Dit kan vereisen dat je taken opdeelt in eenvoudig beheersbare onderdelen).
- De deelnemers, waaraan zij worden toegewezen en details over de planning. Begin hierbij met de product owner.
- Het plannen van tenminste één fysieke vergadering per cyclus.
- Het definiëren van hoe en wanneer je rapporteert over bestede uren en uitgevoerde taken.
- Het plannen van resources ter ondersteuning van initiatieven.
- Het rapporteren over resultaten en promoten hiervan binnen de organisatie.
Teamgrootte
Kijk kritisch naar de omvang van het team. Dit is niet alleen een belangrijk aandachtspunt bij het opstarten van het proces, maar ook iets wat je regelmaat moet her-evalueren. Wij adviseren een aanpak waarbij je werkt met twee virtuele teams:
- Een kernteam dat in ieder geval de product owner, feedbackanalist, data-analist en enkele andere adviesrollen omvat (denk aan de UX’er, consultant of afdelingsmanager).
- Een flexibel team met experts en middelen voor het uitvoeren van verbeteringsinitiatieven.
Het belangrijkste verschil tussen deze twee teams is dat de taken van het kernteam vooraf gedefinieerd en gepland worden, terwijl het flexibele team varieert per sprint. Sommige teamleden kunnen overigens prima deel uitmaken van beide teams. Een voorbeeld is een UX-expert die advies levert over nieuwe initiatieven, maar ook een deel van het werk dat hieruit voortkomt uitvoert.
Bij het samenstellen van deze teams kan je verschillende aanpakken hanteren:
- Een klein kernteam met een externe pool voor ontwerp en ontwikkeling
Het voordeel van deze werkwijze is dat de investeringen in het kernteam – zowel in geld als tijd – beperkt blijven. De ontwikkelkosten zijn afhankelijk van het werk dat per cyclus moet worden uitgevoerd, wat deze aanpak flexibel maakt. De experts die je nodig hebt voor bepaalde taken zitten echter niet stil en zijn vaak al toegewezen aan andere projecten. Dit maakt het realiseren van verbeteringen op de korte termijn een uitdaging.
- Een groot kernteam met ontwerpers en ontwikkelaars
Het voordeel van deze aanpak is dat experts gereserveerd zijn voor het uitvoeren van taken voor het CI-project en al zijn ingewerkt. Teamleden zijn in belangrijke mate zelfsturend en gemotiveerd voor het uitvoeren van hun taak in de beschikbare tijd. Tegelijkertijd zullen er cyclus zijn waarin niet alle teamleden voldoende taken toegewezen krijgen en dus tijd overhebben. Houd daarom minder dringende taken gereed als back-up zodat vrije uren niet verloren gaan.
- Meerdere kernteams met een gedeelde pool van experts
Wanneer je het verbeteringsprogramma écht wilt opschalen kan je met meerdere kernteams werken, verdeeld over afdeling of locatie. Op deze schaal kan je een gereserveerde pool met experts hanteren die deze kernteams delen. Talent uit deze pool wijs je op basis van prioriteiten toe aan de verschillende kernteams. De poolmanager bespreekt de prioriteiten met de product owners van de verschillende kernteams. Let op: deze pool levert de experts je nodig hebt voor algemene taken, zoals de UX, het ontwerp en front-end development. Voor gespecialiseerde en applicatie specifieke taken zijn vaak experts uit de rest van de organisatie nodig, waarover je dus alsnog moet onderhandelen.