Auteur: Dimitry Koteris

Wat een POCCE werk!

Tips en trucs voor een geslaagde POC (Proof Of Concept)

Een aantal keer per jaar krijg ik de vraag om een proof of concept te begeleiden bij een bedrijf. Meestal wil de prospect vertrouwen krijgen in ons en in de software die wij leveren. Dit zijn eigenlijk mini projectjes waarin we in korte tijd veel werk verzetten onder hoge druk (bij een geslaagde POC mogen we meestal starten met het uiteindelijke project). Het is niet altijd even duidelijk wat nu precies de verwachtingen zijn van beide kanten. Daarom deel ik graag mijn ervaringen en tips zodat jouw POC een toffe ervaring wordt en het begin van een partnership met je softwareleverancier... En hopelijk zijn wij dat dan :-)

1. "Gratis heeft geen waarde"

Een POC heeft als doel om het vertrouwen te wekken in de leverancier of in een bepaalde maatwerkoplossing. Op het moment dat jouw POC succesvol is gebleken, kun je starten met de implementatie en hoef je dus niet meer bang te zijn dat de gewenste oplossing niet gaat werken. Dit geeft erg waardevolle rust en controle. De leverancier zal mensen (consultants) moeten vrijmaken en inplannen op de POC. Dit zijn gewoon betaalde uren voor zowel de consultants als jouw eigen medewerkers. Zij zullen hun best doen om focus te houden en zoveel mogelijk uit deze uren te halen. Wanneer dit gratis aangeboden wordt, loop je het risico dat men zich met andere zaken bezig gaat houden.. Voor consultants zijn dit betaalde zaken, voor jouw medewerkers zijn dit de normale werkzaamheden.

Hier is het verschil met een gewone "demo" heel duidelijk. Een demo is gratis, maar bevat meestal niet de specifieke "maatwerk"vragen die voor jou zo belangrijk zijn.

2. De leverancier en de klant bepalen samen de case

Als het goed is heeft jouw leverancier ervaring met implementaties en kan dus een veel realistischer inschatting maken van wat er mogelijk is om te laten zien in de POC. De klant (of prospect) kan aangeven of dat voldoende is om vertrouwen te krijgen in de oplossing. Jouw leverancier wil absoluut met jou in zee: vertrouw dus op de expert.

3. De klant bepaalt de acceptatiecriteria

Als klant of prospect bepaal jij wanneer je de POC geslaagd vindt of niet. Maak hiervoor duidelijke acceptatiecriteria. Maak ze Specifiek, Meetbaar en Realistisch. Doe dit vooraf en wijzig dit niet meer.

  • Een voorbeeld van hoe het niet moet is: "Alle user cases moeten 100% naar wens voldoen" (ja en de klant kan later nog de wensen aanpassen zeker).
  • Een voorbeeld van hoe het wel moet: "User case 1: Alle medewerkers moeten kunnen inloggen op een veilige manier, deze moet bestaan uit 2 factoren: 1 - een gebruikersnaam en wachtwoord die je weet en 2 - een device die je bij je draagt. (duidelijk omschreven, de leverancier weet precies wat er gemaakt moet worden en jij weet wanneer het voldoet, CHECK!)

4. De leverancier bepaalt de planning

Als klant heb je geen inzicht in de oplossing en hoe die tot stand moet komen. De leverancier zal dit veel beter kunnen inschatten. Volg dan ook de planning die de leverancier realistisch lijkt, wees natuurlijk kritisch maar wijk hier niet te veel vanaf. Vaak moet er veel opgeleverd worden binnen korte tijd en hoge druk, het laatste dat je wilt is dat mensen zich al in de stress gaan werken vóórdat je uiteindelijke project überhaupt is gestart.

5. De case is kort en krachtig

Je hebt als het goed is al een aantal zaken gezien in een demo of als je pech hebt in een Powerpoint. Nu volgt de grote test: gaat mijn "probleem" wel opgelost worden door deze leverancier? Het is dan ook moeilijk voor bedrijven om zich in te houden en focus aan te brengen. Je kunt niet verwachten dat het hele systeem al voor je wordt ingericht, dat je even mag snuffelen en dan pas bepalen of je het wilt kopen. Het doel van een POC is om vertrouwen te krijgen. Kies maximaal 5 cases uit en baseer daar je vertrouwen op. Als dit lukt dan heeft de leverancier zichzelf bewezen. Als het jou niet lukt om je te beperken tot 5 cases dan moet je je afvragen of het wel zo verstandig is om nieuwe software aan te schaffen. Je bent er misschien nog niet aan toe.

Ik krijg regelmatig POC-aanvragen waarin er echt wordt gevraagd om "eventjes" meer dan 100 cases op te lossen. Het is lastiger om van 100 cases terug te gaan naar 5, dus hebben we vaak toch te maken met uitgebreide projecten terwijl de prospect dat helemaal niet had verwacht. Achteraf wordt bijna altijd aangegeven door de klant (geen prospect meer natuurlijk) dat minder cases veel prettiger was geweest. Ooit heb ik een POC begeleid waar meer dan 300 cases in stonden. Achteraf tijdens het project wist de klant zelf niet eens meer wat er in stond en waarom dat destijds belangrijk was, zonde van ieders tijd!

6. Manage het als een project

Zorg ervoor dat je resources vrij maakt en dit er niet "even bij doet", je hebt een projectteam nodig met minimaal:

  • Een projectmanager die dagelijks dit project begeleidt
  • Een expert vanuit de organisatie die kan bepalen of de acceptatiecriteria zijn gehaald

Daarnaast zal de leverancier een expert leveren en meestal een projectleider. Vraag bij je leverancier na hoeveel tijd je moet vrijmaken en doe dit dan ook. Maak net als bij een echt project een scope, planning en zorg dat er een kop en een staart aan zit.

Een paar project-randvoorwaarden die wat mij betreft altijd moeten voorkomen in een POC:

  • Stel een projectmanager aan (klant)
  • Vraag om een projectleider (leverancier)
  • Maak tijd vrij - echt vrijmaken dus, niet alleen opschrijven ;-)
  • Zorg voor minimaal 2 officiële testmomenten op locatie met de expert van de leverancier en eventueel andere betrokkenen
  • Niet langer dan 6 maanden, dan kun je net zo goed met het uiteindelijke project starten

7. Wees betrokken

Het is een open deur, maar een POC is ook om kennis te maken met je leverancier en het product. Zorg voor regelmatig overleg en laat de experts vanuit jouw organisatie ook voldoende deelnemen aan de sessies met de consultants. Wees ook gretig in het testen en samenwerken en vier de oplevermomenten samen met elkaar.

Betrokken projectmedewerkers komen nooit voor verrassingen te staan. Je merkt dan al in een vroeg stadium wat de uitkomst gaat worden van de POC.

8. Gebruik de resultaten

In softwareland is het eenvoudig om de resultaten van een POC te hergebruiken. Soms kun je op deze basis verder bouwen of simpelweg copy-pasten. Ook is het belangrijk dat iedereen weet wat de uitkomsten van de POC waren, ook eventuele nieuwe projectmedewerkers. Een goed registratiesysteem is hierbij noodzakelijk. Vraag je leverancier of zij hier een systeem voor hebben, want zij hebben dit vaker gedaan.

9. En dan verder...

Na de POC ga je meestal verder met het "echte" project. Er zijn nog een paar laatste tips die je kunnen helpen zoveel mogelijk succes te halen uit zowel de POC als het uiteindelijke project. De eerste is dat je een duidelijke break neemt. Zeker wanneer de POC lang heeft geduurd, zorg er dan voor dat alle betrokkenen tijd hebben om "even bij te komen". Maak de break niet te kort, want we hebben het meeste werk nog voor de boeg. Sommige klanten willen zoveel mogelijk waar voor hun geld en hebben een financiële afspraak gemaakt over de POC. Nu is de tijd om deze rond te maken. Neem vervolgens de POC op in het projectplan en wijk hier niet meer vanaf. Er heeft veel tijd en moeite in gezeten dus waardeer dat ook.

Veel succes!

Iedere POC heeft weer zijn eigen unieke uitdagingen, dat maakt het juist leuk!
Heel veel succes met je eigen projecten en mocht je vragen hebben neem dan gerust contact met me op.

Meer lezen?