‘Een goede programmeur heeft maar een half woord nodig’
Eén van onze klanten roept onze hulp in voor de selectie van een nieuw bedrijfssoftware pakket. Al snel blijkt dat de klant amper twee jaar geleden geïnvesteerd heeft in een ‘eenvoudig en goedkoop’ basispakket, waarin ze gedeeltelijk zelf, en gedeeltelijk met hulp van de leverancier, extra functionaliteit kunnen bijschrijven. De implementatie liep niet op wieltjes en 80% van de basisoplossing wordt vandaag nog steeds niet gebruikt.
Struikelblokken zijn de invoer van data (de klant beschikt niet over een degelijke database die de applicatie van de nodige gegevens voorziet), de teleurstellende snelheid van de applicatie (de gebruikers worden daardoor geremd om de applicatie te gebruiken) en het feit dat de ondersteuning van de leverancier plots is weggevallen. Wanneer we de leverancier contacteren, blijkt dat die ondertussen van de markt is verdwenen. Het pakket werd gemaakt door programmeurs op een ver tropisch eiland, aan supergoedkope lonen. Omdat maatwerk op die manier zeer goedkoop werd, heeft de leverancier nooit geinvesteerd in stabiele versies van het product. Elke klant beschikt dus over een min of meer unieke versie: programmering à la carte. Dat is plezierig voor wie erg specifieke noden heeft, maar een pest bij het doorvoeren van updates.
De leverancier stelt voor dat we rechtstreeks contact opnemen met de programmeurs op het verre eiland, maar beschikt (voorlopig) niet over een Belgische contactpersoon die de noden van de Belgische klant kan vertalen in instructies voor de verre programmeurs. Ondertussen blijft onze klant zitten met een onafgewerkte implementatie, zonder support, en met de twijfel ‘moeten we nu al dan niet herbeginnen met een nieuwe leverancier en een nieuw product’.
Stap 1: verwachtingen in kaart brengen
Wij raden onze klant aan om even afstand te nemen van het leveranciersprobleem en eerst en vooral hun eigen verwachtingen in kaart te brengen. Daarbij is het belangrijk om niet te vertrekken vanuit een feature lijst van een product, maar vanuit een analyse van de concrete noden en een schets van de gewenste verbetering. Een verkoper is NIET de geschikte persoon om een dergelijke analyse uit te voeren. De klant kan dat geheel of gedeeltelijk zelf doen, en/of een onafhankelijke adviseur inschakelen. Belangrijk bij deze oefening is om alle belanghebbenden te horen: business verantwoordelijken, gebruikers, de technische ploeg die instaat voor onderhoud en support, alle afdelingen die informatie leveren aan de oplossing en/of informatie nodig hebben uit de oplossing, enzovoort.
Tijdens deze stap zoeken we een antwoord op de volgende vragen:
Stap 2: verwachtingen vertalen in projectscope
Na de oefening uit stap 1 is de positie van onze klant versterkt. Hij kent nu immers zijn eigen verwachtingen, en kan die communiceren met de projectmanager en potentiële leveranciers. Hij heeft zijn eigen ‘agenda’ en is veel minder afhankelijk van een lijst met mogelijkheden die de (interne of externe) leverancier hem aanbiedt. De volgende stap is de verwachtingen van de klant zo precies mogelijk omzetten in een project scope. Dat is een taak voor de projectmanager.
De projectmanager speelt hier de rol van facilitator. Een facilitator graaft dieper dan een analist en geeft een antwoord op de ‘ware’ verwachtingen binnen het bedrijf. Hij beperkt zich niet tot een technische beschrijving van producteigenschappen, maar peilt naar alle vereisten om tot een werkende oplossing te komen. Hij werkt via interviews en/of workshops waar technici, gebruikers en business vertegenwoordigers samen de vereisten van de oplossing bepalen.
Chris Kindermans (Proyect@): ‘De scope (men kan het ook een lastenboek noemen) beschrijft de noden, wensen en verwachtingen van een klant gezien door de ogen van de projectmanager. Hij vertaalt hierbij de verwachtingen in iets wat hij kan maken, binnen het kader opgelegd door de klant, en gebaseerd op een aantal gedocumenteerde veronderstellingen. De projectmanager beschrijft ook duidelijk wat NIET in de scope zit. Op die manier wordt het project ondubbelzinnig afgebakend.’
Bij deze ‘vertaling’ kan een aantal dingen mislopen:
Ives De Saeger (P41): ‘Het omzetten van de verwachtingen van de opdrachtgever in een projectscope hangt af van de kennis en de creatieve inleving van de opdrachtgever, de projectmanager en de uitvoerder. De opdrachtgever is opgetogen over het concept/idee dat hij heeft bedacht. Pogingen om dit concept te veranderen stuiten meestal op verzet. Nochtans kan de opdrachtgever nog méér verwachten als hij input aanvaardt van derden en in een open sfeer alternatieven overweegt. In essentie heeft dit te maken met het verschil tussen ‘wat er is’ en ‘wat men kent’. Vanuit een technologisch/technisch standpunt is het aantal mogelijkheden om het concept te realiseren eindig. Toch kent de opdrachtgever niet noodzakelijk alle mogelijkheden. Het schetsen van de mogelijke aanpakken helpt de opdrachter om een beter inzicht te krijgen in wat er mogelijk is. Zo kan hij zijn verwachtingen concreter maken.’
Chris Kindermans (Proyect@): ‘Vooral woorden en begrippen als ‘gebruikersvriendelijk’, ‘performant’, ‘implementatie’ enzovoort dienen ondubbelzinnig en SMART te worden beschreven.’
Stap 3: akkoord bereiken rond de projectscope
Op dit moment worden de partijen het eens over de scope. Ze zijn nu klaar om een document te ondertekenen dat wederzijds bindend is. Ook hier zijn een aantal aandachtspunten nodig:
Natuurlijk stopt het verhaal niet bij stap 3. Verwachtingen kunnen immers veranderen, en als dat gebeurt, dan zal de projectscope volgen. Daarom onderscheiden we nog 2 stappen:
Over stap 4 en stap 5 vertel ik meer in het volgende artikel.
Ann Van Herreweghe
