01
De zwakste aanname getoetst
Zoek zelf de aanname die de reviewer zal kiezen, en toets die vóór de review.
OneDayBuild, het bouwdagmerk van Appfront
Prototype voor de review van je business case
In grotere organisaties gaat een business case langs een review: finance, een portfolioboard of een architectuurraad toetst de aannames voordat er budget komt. De reviewer zoekt de zwakste aanname, en bij een digitaal project is dat vaak de vraag of het technisch kan en of gebruikers het oppakken. Een werkend kernonderdeel maakt van die aanname iets wat getoetst is. Wij bouwen het in één werkdag.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Wat een reviewer zoekt
Een reviewer leest een business case op zoek naar de aanname die, als hij niet klopt, de hele case omver haalt. Bij digitale projecten is dat vaak de techniek of het gebruik.
Een business case-review is een toets, geen presentatie. De reviewer heeft de case gelezen, heeft de aannames op een rij gezet en vraagt door op de zwakste. Bij een digitaal project zijn dat vaak twee aannames: dat het technisch kan zoals beschreven, en dat de gebruikers het gaan gebruiken zoals de besparing veronderstelt.
Een werkend kernonderdeel toetst beide vóór de review. De technische aanname is geen belofte meer, en als een paar gebruikers het hebben gebruikt, is de gebruiksaanname onderbouwd met wat ze deden. De reviewer kan zijn vragen richten op wat nog onzeker is: de opbrengsten, de kosten van beheer, de planning.
De opbrengsten blijven een schatting. Een prototype zegt niet hoeveel een organisatie bespaart; dat hangt af van schaal, adoptie en tijd. Presenteer het als getoetste aanname, niet als bewezen rendement.
02
Gebruik als onderbouwing
Een paar gebruikers die de kern gebruikten, zeggen meer over adoptie dan een aanname in een spreadsheet.
03
Een scherpere review
De vragen gaan over wat echt onzeker is: opbrengsten, beheer, planning. Niet over of het kan.
04
Geen rendementsbewijs
Een prototype bewijst dat het werkt, niet wat het oplevert. Zeg dat erbij, dan vertrouwt de reviewer de rest.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- Het kernonderdeel dat de zwakste aanname toetst, werkend op voorbeelddata of een export.
- Een opzet om een paar gebruikers het te laten gebruiken en vast te leggen wat ze deden.
- Een korte beschrijving van wat is getoetst en wat de uitkomst was, voor in de business case.
- De code in de repository van je organisatie, wat de review ook adviseert.
Buiten scope
- De business case, de opbrengstberekening en de kostenraming.
- Koppelingen met productiesystemen en echte persoonsgegevens.
- Advies over de besluitvorming of de prioriteiten van de organisatie.
- Het volledige project; daar is het budget voor.
03/06
Hoe de bouwdag verloopt
- Stap 1
De aannames op een rij
Welke aannames draagt de business case, en welke zal de reviewer als eerste betwijfelen.
- Stap 2
De kern afbakenen
Het kleinste onderdeel dat die aanname toetst.
- Stap 3
Bouwen
Werkend op een export of voorbeelddata die op de echte situatie lijken.
- Stap 4
Gebruikers laten proberen
Een paar mensen uit de doelgroep. Wat ze deden en waar ze stopten, gaat in de case.
- Stap 5
Uitkomst beschrijven
Wat is getoetst, wat kwam eruit, en wat blijft onzeker. In de taal van de review.
- Stap 6
Live zetten en overdragen
Live URL, code in de repository van je organisatie en de beschrijving.
Volgende stap
Gaat je business case binnenkort langs een review?
Vertel ons welke aanname de case draagt, wie de reviewer is en wanneer de review is. Dan zeggen we of de kern in één dag werkend te maken is en wat je ermee in de case zet.
04/06
Eerlijk over een review
- Opbrengsten blijven een schatting. Een prototype bewijst dat het werkt, niet wat het bespaart. Een reviewer die dat verschil hoort, vertrouwt de rest van de case meer.
- Een getoetste aanname kan ook falen. Als het niet werkt of niet wordt gebruikt, weet je het vóór de review. Dat is een betere uitkomst dan een goedgekeurd project dat halverwege stopt.
- Interne systemen blijven buiten. Koppelingen met productiesystemen passen niet in een dag. Het onderdeel werkt op een export, en dat staat in de beschrijving.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Je business case draagt een aanname die de reviewer gaat betwijfelen, en je kunt hem alleen verdedigen met een schatting.
- Aan het eind van de dag is die aanname getoetst, en gaat de review over wat echt onzeker is.
- Één dag, vaste prijs, code in de repository van je organisatie.
Volledig traject, Appfront
- De review is positief en het project krijgt budget.
- Het project met koppelingen, beveiliging en beheer, gebouwd op het onderdeel dat er al staat.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Wat bewijst een prototype bij een business case-review?
Dat de technische aanname klopt en dat gebruikers de kern oppakken. Het bewijst niets over opbrengsten, besparing of rendement; die blijven een schatting in de case.
Wat is het verschil met een MT-presentatie?
In een presentatie vertel jij het verhaal. In een review toetst iemand anders de aannames, vaak finance of een portfolioboard. Het prototype helpt daar niet als demo, maar als getoetste aanname.
Welke aanname moeten we toetsen?
De aanname die de reviewer als eerste zal betwijfelen, en die de case omver haalt als hij niet klopt. Meestal is dat de techniek of het gebruik. In de intake zoeken we hem samen.
Mogen we bouwen zonder IT erbij?
Een prototype op een export, zonder koppeling met productiesystemen, valt meestal buiten de regels voor nieuwe systemen; vraag het na. Het gesprek met IT hoort bij de volgende fase.
Wanneer moet de bouwdag zijn?
Vóór de review, met tijd om een paar gebruikers het te laten proberen en de uitkomst in de case te zetten.
Helpen jullie met de business case?
Nee. De case, de opbrengsten en de kosten zijn van jou. Wij bouwen het onderdeel en beschrijven wat is getoetst.
