Blog van Ronald Cornelisse, Resultant bij First Resultancy;

‘Experts can look into the future – but not inside the customers brain’

Is een ‘happy marriage’ mogelijk tussen Best Value en Agile werken?

Het afgelopen jaar intensief bezig geweest met Best Value (Procurement) en daarnaast ook het Agile werken. Een periode waarin ik mijn Telecom/IT praktijkervaring kon combineren met nieuwe methoden en deze praktijk gericht kon inzetten voor de klanten van First Resultancy.

In een notendop, Best Value Procurement, ook wel Prestatie Inkoop genoemd, is een verfrissende manier van het inkoopproces organiseren. First Resultancy is gecertificeerd voor het toepassen van deze methode. Wij zetten die in naast de meer traditionele TCO inkoop methodieken die wij gebruiken voor Telecom & IT trajecten. En Agile werken is (project management) aanpak die zicht richt op het ontwikkelen van een product. Over beide methodes hieronder meer.

Grondlegger van Best Value – Dr. Dean Kashiwagi

Recent hebben wij bij First Resultancy de gelegenheid gehad om de grondlegger van het Best Value Procurement gedachtengoed te interviewen. Hij werd door collega Boudewijn Janssen bevraagd over Best Value Procurement in de context van het inkopen van IT oplossingen. Klik hier voor de video van het interview. Dean geeft aan dat Best Value Procurement erg geschikt is voor het inkopen van ICT producten en diensten. Je laat de expert vanuit zijn kracht acteren en de beste oplossing voor de klant leveren. Als opdrachtgever kan je nooit dé expert zijn. Zeker niet in een zo snel veranderend veld als ICT.

We spraken ook met Dean over Agile werken en we konden ons niet aan de indruk onttrekken dat het lijkt alsof Dean niet zo’n fan van Agile werken is. Hij zegt dat opdrachtgevers en opdrachtnemers die voor Agile kiezen dat doen, omdat ze niet weten wat ze willen. Hij gaf ook aan dat er bij Agile werken meer mensen betrokken zijn en dat er mede hierdoor meer ‘talking’ is en meer noodzaak voor documentatie.

Zijn opmerkingen waren voor mij de aanleiding om dit blog te schrijven en te onderzoeken hoe beide methoden zich tot elkaar verhouden en of ze van elkaar zouden kunnen leren.

Best Value

Best Value is een aanpak die uitgaat van de beste prestatie voor de beste prijs. De gedachte achter Best Value is dat de leverancier de expert is en dat de klant eigenlijk aan de leverancier vraagt zijn gewenste product te specificeren en te leveren, om op die manier de beste prestatie te krijgen tegen de laagst mogelijke kosten. Een belangrijk principe is dat er op een transparante manier samengewerkt wordt in de keten waarbij er ruimte is voor elkaars expertise. De Best Value aanpak komt voort uit Best Value Procurement. Best Value is echter meer dan ‘procurement’, omdat het ook project- en risicomanagement omvat.

Bij Best Value projecten is de opdrachtnemer ‘in the lead’. Op basis van de doelen van de klant, minimale specificaties en zijn expertise, wordt hij in staat geacht om een waardevolle prestatie voor de opdrachtgever neer te zetten. Als expert kent hij de mogelijkheden en de risico’s en neemt verantwoordelijkheid voor het leveren van de afgesproken prestatie. Doordat opdrachtgever en leverancier werken met dezelfde doelstellingen, wordt ‘controle’ en daarmee ook ‘tijd’, ‘ruis’ en onnodige informatie flows geminimaliseerd. De expert is immers kundig en weet hoe te sturen op afwijkingen en risico’s.

Daarnaast gaat Best Value ook verder dan alleen het vinden van de best presterende aanbieder en het contracteren. Het gaat ook over het behalen van de gemeenschappelijke doelstellingen gedurende de contractduur. Best Value werkt daarom om met fases en kan gezien worden als een zogenaamde ‘Waterval methodiek’ als we dit met een projectmanagement bril op bekijken.

bestvalueprocurement

Best Value Procurement levert dus diverse voordelen op:

  • Vooraf een goed inzicht in de risico’s, planning en te leveren prestaties van het project;
  • De Expert krijgt de ruimte om het project naar een zo goed mogelijk resultaat te leiden;
  • Waardoor er een hogere kwaliteit, minder onverwachte kosten, minder tijdverlies door discussie tussen opdrachtgever en leverancier (de expert).

Wat is Agile werken?

Agile (letterlijk behendig, lenig) is een aanpak voor het ontwikkelen van concrete resultaten, bijvoorbeeld software. De aanpak kenmerkt zich door het vermogen om te anticiperen en te reageren op veranderende omstandigheden. Dat gebeurd door steeds in korte, zogenaamde sprints, te werken. Aan het einde van een sprint wordt een versie van het product opgeleverd. Wat dan weer de basis is voor een eventuele volgende sprint en volgende versie. Een ander kenmerk is dat er samengewerkt wordt in multi-disciplinaire teams. Onder de paraplu van Agile vallen verschillende methode en principes zoals Scrum, DevOps, Lean, Kanban, etc.

De origine van het Agile werken is terug te vinden in de IT en dan met name in de software ontwikkeling. Daar had de praktijk uitgewezen dat gedetailleerde specificaties en lange termijn planning bij het ontwikkelen van producten (software, applicaties) vaak toch niet de door de klant gewenste functionaliteiten opleverde. Daarnaast ook vaak niet op tijd en niet binnen budget.

Nu is het is niet zo dat de ontwikkelaars er niets van bakten, zij bouwden tenslotte het product wat tot in den treuren gespecificeerd was door de klant. Maar omdat het hele proces lang duurde ontstond er voortschrijdend inzicht vaak met nieuwe wensen. Die op hun beurt weer leiden tot ‘Change Requests’ en discussies over of die change nu wel of niet al in het projectplan en budget opgenomen was. Zie hier de basis voor de vele vertragingen en kostenoverschrijdingen.

Bij een Agile aanpak gaat dat heel anders. Een van de methoden die onder de Agile paraplu valt is Scrum. Scrum verwijst naar de scrum in rugby. Een scrum team is multidisciplinair. In het team zitten ontwikkelaars, testers, vertegenwoordigers van de klant en mogelijke leveranciers. In zo’n team speelt de ‘ Product Owner’ een belangrijke rol. Hij bepaalt namelijk de volgorde van ontwikkelen van delen van het product. Hij weegt hierbij de belangen van de stakeholders. Daarnaast is er een Scrum master, hij faciliteert en coacht het team. Het 1e op te leveren product wordt op hoofdlijnen geschetst in user stories en taken. Vervolgens wordt het product in zogenaamde Sprints gemaakt. Een Sprint is een vast tijdslot van meestal 2 tot 3 weken. Bij de start staat al het werk in een wachtrij (backlog) en als de product owner bepaald heeft wat er opgeleverd moet worden, wordt het werk in een sprint kick-off toegekend aan een Sprint. Dit proces herhaalt zich diverse keren totdat het product de gewenste eindstaat heeft behaald. Deze korte iteraties laten het toe om al vroeg feedback te krijgen op het product en de gekozen ontwikkel richting. Fail Fast en Fix Early is het idee.

pdca-cyclus

De Plan-Do-Check-Act (PDCA) cyclus is in het bovenstaande verankerd. Alleen zien klanten veel sneller de resultaten en krijgen ook beter zicht op het mogelijke eind resultaat. Dat maakt het mogelijk dat zij de ontwikkeling gerichter kunnen sturen. Soms kan functionaliteit die vooraf bedacht was, door andere opties te gebruiken overbodig worden.

Een ander voordeel van deze manier van werken is dat een klant kan starten met de ontwikkeling van die producten die de meeste waarde toevoegen aan zijn business. Of het nu gaat om het realiseren van besparingen of het genereren van meer inkomsten. Zo’n product noemen we ook wel een Minimum Viable Product (MVP). Zo’n MVP kan snel beschikbaar komen, misschien nog niet met alle opties maar wel werkend. Dat is heel anders dan de meer traditionele manier waarbij een product, dat via een lang waterval traject, met een ’big bang’ gelanceerd wordt. Nog afgezien van de vraag of dat product dan nog aan de verwachtingen voldoet.

Agile versus BVP

Terug nu naar de aanleiding van dit blog, de observaties van Dr. Dean Kashiwagi. Kan je stellen dat klanten voor Agile werken kiezen omdat ze niet weten wat ze willen? En is het zo dat Agile werken meer mensen vraagt en leidt tot meer documentatie? En mijn persoonlijke nieuwsgierigheid, kan je goede kenmerken van beide aanpakken over en weer gebruiken?

Afgezet tegen het doel, zijn Agile werken en Best Value twee verschillende aanpakken.

  • Best Value is bedoeld voor het inkopen van een product of dienst
  • Agile/Scrum is aan aanpak voor het ontwikkelen van een product of dienst.
  • Bij Best Value is de expert in the lead.
  • Bij Agile de klant, de product owner.
  • Best Values aanpak werkt zeer goed in een omgeving waar het probleem duidelijk is en de oplossingen (bij de expert) bekend zijn. De Expert kan hier dan ook echt zijn toegevoegde waarde laten gelden.
  • Agile/Scrum wordt gebruikt voor situaties waar het probleem redelijk goed bekend is maar de oplossing nog onbekend.

welke-aanpakIk denk dat je kan stellen dat in beide werkwijzen een klant echt wel weet wat hij wil. Sterker nog bij beide aanpakken wordt er niet tot in detail gespecificeerd.

Het klopt dat er met Agile meer mensen betrokken zijn en dat er mede hierdoor meer ‘talking’ is maar dat wil niet zeggen dat er dan meer gedocumenteerd moet worden. Een Agile team bestaat uit maximaal 9 personen en verenigt Multiple Subject Matter experts om gezamenlijk tot een oplossing te komen. Er is continue informatie overdracht, zowel op dagelijkse stand-ups als op Sprint basis. Daarnaast zijn er zogenaamde ‘information radiators’ die continue aangeven waar het Agile team zicht bevindt in het project. Dit is transparant en toegankelijk voor iedereen. Dus geen dikke status rapportages nodig. En dan is er nog de regel uit het Agile Manifesto die zegt: “Werkende software boven alles omvattende documentatie”.

En hoe zit het dan met de uitwisselbaarheid van beide manieren van werken? Binnen de fasen van Best Value zie ik zeker mogelijkheden om een Agile manier van werken toe te passen. Bijvoorbeeld in Fase 1 – de Pre-selectie fase kan je heel goed met de vorming van een Agile kernteam tot de juiste functionele eisen en wensen komen. Die vervolgens weer aan de potentiele Experts voorgelegd kunnen worden. En in de uitvoeringsfasen zou je op een sprint-achtige manier kunnen werken. Wat het mogelijk maakt voor de leverancier om de risico’s beter te managen.

Deans statements is vaak “Experts can look into the future” zij weten wat mogelijk is en kunnen zo de klant het beste helpen. Ik zou daaraan willen toevoegen – “But not inside the customers brain” – ik geloof dat door op een Agile/Scrum manier met de klant te werken je echt komt bij wat de klant wenst. Dus gebruik vooral ‘the best of both worlds’.