Enkele weken terug was ik de moderator bij een door KPMG en COOLProfs georganiseerde
CIO ontbijtsessie. Het onderwerp van de sessie was de vraag hoe nieuwe strategieën en innovatieve ontwikkelingen kunnen worden omgezet in goede, flexibele en betaalbare IT-oplossingen. Eén van de zaken die aan bod kwam, was hoe in Agile-projecten slim gebruik gemaakt kan worden van de kennis en ervaring van gebruikers*. De genoemde leerpunten wil ik u niet onthouden.
Eén van de principes van the Agile Manifesto is: people and developers must work together daily throughout the project. De achterliggende gedachte hierbij is dat de kwaliteit van het informatiesysteem en de gebruikersacceptatie toenemen als gebruikers tijdens de ontwikkelfase betrokken zijn. Maar gebruikersparticipatie is pas effectief als gebruikers daadwerkelijk beschikbaar zijn, bevoegd zijn om beslissingen te nemen, over voldoende kennis beschikken en de juiste vaardigheden hebben. En dat blijkt in de praktijk toch best lastig te bewerkstelligen.
Tijd
Direct bij dat ‘beschikbaar zijn’ gaat het vaak al mis. Juist de key users hebben doorgaans een overvolle agenda, waardoor in de praktijk hun daadwerkelijke betrokkenheid bij het project vaak tegenvalt. Daarom zal alles in het werk moeten worden gesteld om de klant in een vroeg stadium en op regelmatige basis te betrekken. Wat helpt is om de gebruikers formeel tijd toe te kennen die ze aan het project kunnen besteden.
Invloed
Met ‘bevoegdheden om beslissingen te nemen’ wordt gedoeld op echte invloed van de gebruikers op het te ontwikkelen systeem. Het komt wel eens voor dat gebruikers puur voor de vorm of ‘omdat het zo hoort’ worden betrokken, zonder dat er iets met hun inbreng wordt gedaan. De kans is groot dat dit soort schijnbetrokkenheid een tegengesteld effect heeft en negatief doorwerkt in de kwaliteit van het systeem. Of, erger nog, dat we verzanden in polderiaans geneuzel. In dat verband pleitte ik al eens voor de instelling van een bouwpastoor.
Kennis en vaardigheden
Waar de eerste twee voorwaarden voor effectieve gebruikersbetrokkenheid nog wel relatief gemakkelijk zijn in te vullen, ligt dat bij ‘over voldoende kennis beschikken’ en ‘de juiste vaardigheden hebben’ wat lastiger. Het uitvoering geven aan een proces of gebruik maken van een systeem vergt andersoortige kennis en andere vaardigheden dan die nodig zijn voor het inrichten van een proces of het modelleren van een systeem. Voor inrichten en modelleren zal een gebruiker wat meer high-level naar een proces, een systeem en zijn eigen handelen moeten kijken. Gebruikers hebben echter vaak een te operationele mindset, waardoor ze niet loskomen van de bestaande processen. Door gebruikers snel iets tastbaars te geven om de mogelijkheden te laten zien, maak je ze als het ware slimmer en kunnen ze gemakkelijker reflecteren en een effectieve bijdrage leveren.
Proactieve IT
Anderzijds moet een grote gebruikersbetrokkenheid zich ook niet tegen de IT-organisatie gaan keren. Dat gebruikers zo enthousiast worden en met zoveel vragen en wensen komen dat Functioneel Beheer overbelast raakt. Om de innovatiekracht vanuit de organisatie optimaal te benutten en het tegelijkertijd behapbaar te houden voor Functioneel Beheer, kan een meer proactieve houding van de IT-organisatie uitkomst bieden. Innovatie is immers een kwestie van sparren en als Functioneel Beheer zelf nieuwe ideeën aandraagt kan het een en ander worden gekanaliseerd en toch optimaal worden geprofiteerd van de kennis en vaardigheden van gebruikers. In plaats van een revolutie is er dan sprake van een evolutie.
* Ik gebruik “gebruikers” hier met enige schroom (zie ook deze link), maar vooruit.
Wat we rond 1990 bij een grote klant hebben kunnen bereiken, is dat inzet in ons project voor materie-deskundigen een goede stap was in hun carriëre. Dus tussen 2 ‘normale’ jobs in werden ze bij ons geplaatst. Geen zorgen dus dat hun normale werk in het gedrang kwam (of nog erger: moeiteloos doorging).