Een Proof of Concept (PoC) is een methode om de praktische haalbaarheid van een concept, theorie, technologie, idee of functionaliteit te bepalen.
Een PoC wordt toegepast in het beginstadia van productontwikkeling, de methode zal worden gebruikt om te beoordelen of het idee gerealiseerd zou kunnen worden. Het is een ‘try and test’ methode. Je test feitelijk een aanname, waarvan je wilt weten of het concept of idee uitvoerbaar is.
Er zijn meerdere definities van een PoC. Het oorspronkelijke doel was om te bepalen of een idee technisch uitvoerbaar was. De term is namelijk voor het eerst gebruikt door NASA om het onderzoek naar de haalbaarheid van een technische innovatie te duiden.
Daarna zijn er allerlei aanvullingen gekomen, waarbij sommige definities zelfs de klant al meenemen in de definitie. De meerderheid van de PoC-definities hanteert een vorm van bovenstaande stelling met toevoegingen als: dat een PoC een interne activiteit is, die beperkt is in omvang en niet volledig behoeft te zijn.
Door gebruik te maken van een Proof of Concept leer je of het idee ontwikkeld kan worden en valideer je de technische haalbaarheid. Een PoC wordt veel toegepast binnen software ontwikkeling. De kernvraag voor alle PoC’s:
Is het concept haalbaar?
Wat is het doel van een PoC?
Er zijn verschillende fasen in het tot stand komen van een idee naar product. Er is derhalve ook sprake van een aantal methodieken. De theoretische volgorde is: eerst een Proof of Concept (PoC), dan een Prototype, vervolgens een pilot en dan een Minimum Viable Product.
Agile hanteert iteratieve stapjes, waardoor het lijkt dat een MVP alle voorgaande stappen heeft geïntegreerd in één stap.
Zoals je in onderstaande afbeelding kunt zien is er geen harde scheidingslijn per methodiek. Hoewel het gescheiden stappen zijn, zijn er verschillende interpretaties over wat men waar meeneemt. Onderstaand overzicht toont tevens wat stakeholders herkennen.
Een overeenkomst tussen alle stappen is dat ze allemaal een build-measure-learn-loop hanteren. Dit artikel beschrijft de eerste stap: een Proof of Concept (PoC).
Zoals in de inleiding al is aangegeven is een Proof of Concept (POC) een beperkte activiteit om het ontwerp, idee of de aanname te testen. Het belangrijkste doel van het ontwikkelen van een POC is het onderzoeken van de functionaliteit en het verifiëren van een bepaald concept of theorie die in de later benodigde verdere ontwikkeling kan worden bereikt.
Het is een intern gerichte activiteit, men kijkt nog niet naar de buitenwereld. Je wilt tijd en geld besparen door gericht te kijken of je het idee uberhaupt zou kunnen uitwerken.
Dit kan één concept zijn of meerdere samenhangende concepten tegelijkertijd.
Een groot misverstand is dat men denkt dat een PoC laat zien HOE het product ontwikkeld zou kunnen worden. Dat is echter de functie van een Prototype, een Proof of Concept (PoC) laat zien dat een product, systeemfunctie of een increment ontwikkeld KAN worden.
Uit een PoC komen geen echte ‘deliverables’ zoals in een project, het onderzoekt de haalbaarheid van het concept, idee of project. En niet meer.
Het advies is om een PoC in te zetten zodra je geen zekerheid over de haalbaarheid van het idee. Veelal ontstaat dit doordat het een volledig nieuw idee is, gebaseerd is op technologische ontwikkelingen, een eerder project mislukt is, kosteneffectief wilt werken of er sprake is van een hoge investering.
Wat de reden ook is, een PoC zal je een duidelijk beeld geven of het idee te realiseren valt. Omdat de PoC veelal in het begin van een ontwikkelingstraject word ingezet bespaar je ook hoge kosten. Let wel op de doorlooptijden, het adagium van agile werken blijft: zo snel mogelijk in gesprek met de klant.
Een wolkenkrabber?
Stel je nu een voor dat je architect bent en je een geweldig idee hebt. Je wilt een wolkenkrabber bouwen waar planten in, op en aan het gebouw een integraal onderdeel van het concept is. Stel je eens voor dat dit is nog nooit eerder gedaan, maar je voelt aan je klompen aan dat hier een mogelijke klantvraag is.
De logische PoC-vraagstelling is dan: Is het idee haalbaar?
Dat ga je natuurlijk niet ondervinden als je hiervoor de wolkenkrabber eerst moet bouwen. Of dat je naar klanten of investeerders stapt met de mededeling dat je een leuk idee hebt.
Dat heeft mogelijkerwijs ook nadelen met zich mee. Bij een ja, is er een verwachtingspatroon geschapen. Als dan blijkt dat het zelf niet kunt maken, kan wellicht een ander het wel. Het idee is dan al gedeeld en zal verder gedeeld worden. Dus vlieg je het bij voorkeur anders aan.
Je zult eerst zelf eens moeten berekenen of de toevoeging van het enorme gewicht technisch wel haalbaar is. Het ontwikkelen van een POC is de snelste en meest accurate manier om aannames over het concept te valideren of te ontkrachten.
Je focust je dan primair op de aanname of je de wolkenkrabber technisch gezien kunt bouwen. Een PoC toont in bovenstaand voorbeeld aan dat het productconcept zowel functioneel is als ontwikkeld kan worden.
Toepassingen van een POC
Een Proof of Concept (PoC) focussed zich op de haalbaarheid. Waarom? Zou jij investeren in iets wat wel leuk klinkt, maar niet mogelijk is. Gewoonweg omdat het (nog) niet kan.
Overigens is dit is een regelmatig gemaakte fout van visionairs. Het ene fantastische concept na het andere, maar welke wordt door een organisatie gekozen om nu te ontwikkelen? Een simpel antwoord: het concept dat haalbaar is en rendement kan leveren. Zo was bovengenoemde wolkenkrabber 50 jaar geleden onmogelijk om te bouwen. Nu is het een realiteit.
Overigens kunnen de toepassingen van een PoC per organisatie verschillend zijn. Zo zal een Start-up vooral geïnteresseerd zijn of het product financieel haalbaar is. Organisaties die PoC’s toepassen voor softwareontwikkeling steken hun PoC vermoedelijk in vanuit de processen, om oplossingen te vinden voor technische problemen. Een aantal organisaties integreren een PoC in een MVP en in hun agile ritmieken.
Zo zijn er talloze voorbeelden, de overeenkomst is dat je met een PoC op zoek bent naar bepalende productkenmerken, voordat je start met ontwikkeling. Laten we het in dit kader eens hebben over een concept of idee die door een IT-activiteit ontwikkeld dient te worden.
Welllicht wil je als eerste graag weten of de huidige systemen of aanwezige kennis daar toereikend voor zijn. Dit is vooral belangrijk als je bijvoorbeeld nieuwe technologieën wilt verkennen, je leert als team dan wat de mogelijkheden zijn en deze kennis kun je delen. Een ander belangrijk punt is dat je de interne klant met zekerheid kunt aangeven je het gevraagde kunt opleveren.
De Proof of Concept methode
Laten we eens de belangrijkste zaken van een PoC opsommen:
- Doel: Identificeert de operationele haalbaarheid van het concept
- Doelgroep: interne organisatie
- Validatie: Is dit concept een haalbare oplossing?
- Techniek: een idee vereist veelal technische expertise om het concept door te lichten, de PoC creëert in ene vroeg stadium betrokkenheid.
- Kosteneffectiviteit: Een PoC is geschikt om interne budgetten vrij te maken, het is slechts een geringe investering. Je levert tevens het bewijs dat de toekomstige investeringen in de toekomst kunnen functioneren. Eigenlijk toon je aan dat als het idee ook echt gebaseerd is op een klantvraag er rendementen mogelijk kunnen zijn.
- Kosten: een PoC is een interne aangelegenheid. Dit wil je niet inkopen.
- Leren: een PoC draagt bij aan de leercyclus van een organisatie.
- Gebruiker: deze is nog niet in scope, maar een ontwikkelaar heeft vanzelfsprekend wel een globaal beeld o.b.v. het concept.
En legt een fundering voor vervolgstappen. Een PoC levert input voor een prototype en veelal een Minimum Viable Product.
De organisatievraag
Er zijn een aantal vragen waarbij je direct kunt bedenken dat een PoC passend zou kunnen zijn in jouw organisatie:
- Zou dit idee technisch uitgevoerd kunnen worden?
- We hebben een idee, maar hoe maken we intern budget vrij?
- Kunnen we leren van een nieuwe technologie om een klantwens in te kunnen vullen?
- Kunnen we op voorhand weten of een concept interessant genoeg is om te ontwikkelen?
- Zullen we pas starten met technische ontwikkeling als we meer weten?
Deze vragen kunnen de aanleiding zijn om te starten met een Proof of Concept.
De 5 processtappen van een PoC
Hoewel er veel varianten zijn van hoe je een Proof of Concept (PoC) inricht, zijn er 5 algemene processtappen te benoemen
- Doelen en requirements
- Plannen: tijd, inspanning en afstemming
- Een team neerzetten
- De gewenste resultaten
- Evaluatie
1. Doelen en requirements
Het is belangrijk om je te realiseren dat een PoC gefocussed dient te zijn op één punt. In het voorbeeld van de wolkenkrabber zou dat bijvoorbeeld ‘draagkracht’ kunnen zijn. Het is superbelangrijk dat er sprake van een juiste scope is. Je hebt namelijk niets aan de bevindingen als er achteraf blijkt dat het verkeerde is onderzocht.
Een brainstormsessie kan veel inzichten verstrekken, dus is dat zeker zinvol. Maar, als er daardoor teveel zaken tegelijkertijd worden meegenomen als uitzoekwerk, dan is het al snel geen PoC meer, maar een volwaardig project. Dus een sterke focus op de scope.
Dit is een prima stap om na te denken over de benodigde resources. Wie is de sponsor? Wat heb je nodig? Kortom, geld, tijd en mensen.
Een PoC in een IT omgeving richt zich vaak op een bepaald gebied van het systeem. Realiseer je dat je meerdere POC’s nodig zou hebben om verschillende onderdelen te kunnen beoordelen.
Vanzelfsprekend helpt het als een Product Owner heel helder de scope uitlegt en tijdens het proces van de PoC beschikbaar is.
2. Plannen: tijd, inspanning en afstemming
Hoewel er geen harde doorlooptijd is vanuit de PoC filosofie, hanteren velen dat een PoC binnen een sprint dient te zijn afgerond. Sommigen leggen de PoC vast in een sprint binnen Scrum.
Regelmatig is er echter sprake van een mini-team (2 a 3 members) die vrij snel kunnen beoordelen wat haalbaar is. Wat het eindresultaat ook is, de opgedane kennis zal worden gedeeld.
Om de inspanningen goed vast te leggen hanteert een PoC ook zaken als planningen, taken, verantwoordelijkheden en een vastleggingsmethode. Goede hulpmiddelen hiervoor zijn: dashboards, Kanban borden of een Gantt Chart.
Al bij het plannen is het zaak om zorg te dragen voor een goede afstemming, voortdurende communicatie tussen de betrokken is essentieel om succesvol te zijn.
3. Een PoC-team samenstellen
Een PoC team is zoals zojuist aangegeven beperkt van omvang, deze members dienen natuurlijk wel over de kennis en vaardigheden te beschikken om een goed oordeel te kunnen vellen. Jouw keuze voor deze members is essentieel voor het resultaat.
Denk eens na of en welke begeleiding ze nodig hebben, een coach, Product Owner of een technisch ondersteunend manager.
4. De gewenste resultaten van de PoC
Denk voordat je de middelen inzet nog eens goed aan de scope van de PoC. Want als je niet het juiste vraagt, krijg je weliswaar de juiste antwoorden op die vraag, maar dan heb je er helaas niets aan.
Welke eisen en metrics ga je hanteren? Wat is het bedrijfsproces dat geraakt kan worden? Welke doorlooptijd is acceptabel? Wie presenteert wat? Hoe worden stakeholders meegenomen?
Hoewel het belangrijkste doel is dat het product gebouwd kan worden en haalbaar is, volstaat dit als enige antwoord. Het is van essentieel belang om te realiseren dat een PoC concepten en theorieën toetst op en inzichten levert in:
- Haalbaarheid.
- Belemmeringen (in het proces).
- Ervaringen delen
- Feedback voor alle deelnemers.
- Risico inschattingen en mogelijke oplossingen.
Met als uiteindelijk oordeel of er sprake is van een echte mogelijkheid om verder te gaan met het idee.
5. Evaluatie
De terugkoppeling van PoC’s dient plaats te vinden op basis van feiten. Vooraf gedefinieerde metrics helpen om een goede feedback mogelijk te maken.
Er dient immers een harde keuze gemaakt te worden over de haalbaarheid van het concept. Dat doe je liever niet op gevoel, want dan had je ook geen PoC hoeven te doen.
Overigens is het evaluatie moment ook het moment om het juiste interne communicatieproces te starten. Een goede manier van terugkoppelen is namelijk in hoge mate bepalend voor toekomstige activiteiten. De bevindingen kunnen immers leiden tot het schrappen van het idee of tot het verzoek om verder te mogen gaan met een prototype. Waarvoor additionele middelen voor noodzakelijk zijn.
Herkenbare fouten
Een Proof of Concept wil nog wel eens mislukken, niet alleen omdat het idee niet toereikend of niet mogelijk was. Regelmatig spelen andere factoren een belangrijke rol. Een kleine opsomming:
- Eindpresentatie is niet goed afgestemd, de zender en ontvanger spreken een andere taal.
- Geen duidelijke eisen of metrics meegegeven.
- Het bedrijfsproces is niet goed meegenomen in de PoC.
- Een te lange doorlooptijd van de PoC, veelal omdat degenen die betrokken zijn bij de PoC vaak nodig zijn voor andere zaken. Het bekende ‘brandjes blussen’.
- Weinig aandacht voor de creativiteit of sociale aspecten.
- De risico analyse is niet gemaakt of geen maatregelen bedacht tegen de risico’s.
Samenvatting
Binnen agile werken blijft het zaak om zo snel mogelijk in gesprek te gaan met de klant. Ga geen langdurige, arbeidsintensieve en kostenverhogende activiteiten in je proces toevoegen. Blijf in korte iteraties werken!
Een PoC bewijst dat het kan.
Het is in veel gevallen heel wijs om eerst te bewijzen dat het concept gemaakt kan worden, dus voordat je het gesprek met de klant aangaat.
Vanzelfsprekend werkt het ook andersom, als je de vraag van de klant niet voldoende begrijpt is het verstandig om eerst de echte klantvraag te begrijpen. Want ontwikkeling dient te starten vanuit een (latente) klantvraag.
Een belangrijk doel van dit artikel is dat je overziet waar alle processtappen in productontwikkeling voor staan. Daartoe is een PoC beschreven, er is immers sprake van een enorme diversiteit in methodieken en definities.
Het is een absolute noodzaak dat duidelijkheid is welke stap met welke methodiek genomen zal worden EN dat men er over eens is wat deze keuze inhoudelijk betekent.
Onderstaand een korte samenvatting van een Proof of Concept:
- Een PoC verstrekt een duidelijk advies over de haalbaarheid van een idee.
- Bevestigd de mogelijkheden en creëert mogelijkheden om innovatie op te starten.
- Beoordeelt of het realistisch is om het idee verder uit te werken.
- Geeft een goede indicatie voor het geheel.
- Is goedkoper en vraagt minder tijd t.o.v. een volledig project.
- Geeft inzicht in de risico’s, maar ook inzicht in fouten in het proces.
Een PoC is primair een interne aangelegenheid en wordt meestal niet aan de klant getoond. Het is een onderzoek of men met het idee wel verder moet gaan, je stopt als het niet ontwikkeld kan worden of de mogelijkheden te beperkt zijn.
Zelfs als de PoC succesvol is, hoeft dit niet automatisch te betekenen dat men ermee door gaat. Soms kiest men toch liever voor een andere route of stopt men er mee.
Het kan immers zijn dat je het wel kunt maken, maar bij nader inzien toch niet een goede fit is met de organisatie. Bij een goed PoC resultaat zijn de kansen om door kunnen gaan toegenomen. Het is makkelijker om interne financiering los te krijgen, voor bijvoorbeeld een prototype.
Je maakt een prototype om te laten zien hoe het product zal functioneren. Je hebt een werkend model van een mogelijk toekomstig eindproduct. Een prototype is in een ander artikel beschreven.
Tot slot een overzicht van de methodes:
- Een Proof of Concept laat zien dat het gemaakt kan worden.
- Een prototype laat zien hoe het gemaakt is.
- De pilot is een kleinschalige implementatie van het product, concept of idee om de levensvatbaarheid aan te tonen.
- Een MVP vraagt aan potentiële gebruikers of ze jouw productidee nodig hebben of niet. En daarbij onderzoek je tegelijkertijd of je de juiste kernwaarden aanbiedt. Dit lees je in het artikel: Wat is een Minimum Viable Product (MVP)?