Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Agile inkopen kent ook zijn regels

 

Computable Expert

Dick Stegeman
Vennoot, IHomer. Expert van Computable voor de topics Management en Maatschappij.

Agile staat als software-ontwikkelaanpak behoorlijk in de belangstelling en is bijna niet meer weg te denken. De voordelen worden door velen gezien en omarmt. Maar agile kent ook uitdagingen en roept soms vragen op. Afgelopen week werd ik met zo’n vraag geconfronteerd, te weten 'hoe koop je nu eigenlijk agile projecten in'. De vraag kwam uit een instelling die alles volgens de Europese aanbestedingsregels moet inkopen.

De kerngedachte achter de Europese aanbesteding is dat door het aanhouden van objectieve criteria iedereen een eerlijke kans maakt op de opdracht. Geen vriendjespolitiek of achterkamergekonkel maar eerlijke en open aanbiedingen en gunning volgens objectieve criteria. De werkwijze van huidige aanbestedingstrajecten botsen op twee belangrijke punten met een agile-aanpak. Ten eerste probeert men contractueel de volledige scope dicht te timmeren, terwijl men bij een agile-aanpak kiest voor een timebox-aanpak waarbij, rekening houdend met voortschrijdend inzicht, in de vastgestelde tijd zoveel mogelijk business waarde wordt gerealiseerd. Ten tweede vergt de Agile-aanpak commitment van de opdrachtgever om deel te nemen aan het ontwikkelproces en daarin verantwoordelijkheid te nemen.

Laten we ervan uitgaan dat de opdrachtgever hiervan doordrongen is en bewust een keuze wil maken voor een partner die de oplossing volgens een agile-aanpak wil realiseren, op basis van welke criteria moet deze keuze dan gemaakt worden? Het uurtarief als criterium valt al snel af. Hoe lager het uurtarief, hoe meer uren er weliswaar gewerkt kan worden aan het creëren van business waarde, maar er bestaan. enorme verschillen in productiviteit tussen teams. En dan praat ik niet over een paar procenten, maar eerder over factoren verschil.

Nou heb ikin  het verleden nog wel eens op basis van de Rapid Application Development methode aanbiedingen gemaakt. Hierbij werd dit probleem van objectiviteit omzeilt door een objectieve functiepunten telling en een prijs per functiepunt af te spreken.Hier waren immers industrie standaarden voor en onafhankelijke partijen zouden de uitkomsten kunnen verifiëren. Bij agile wordt er gebruik gemaakt van story points. Dat lijkt wellicht in eerste instantie behoorlijk op functiepunten, maar dat is maar uiterlijke schijn. Story points worden niet door de aanbesteder bepaald maar door een bouwteam. Ze zijn een inschatting van de hoeveelheid werk relatief ten opzichte van een team specifieke maat. Ze zijn dus niet overdraagbaar en kunnen door een onafhankelijke partij dan ook niet getoetst worden.

Rest volgens mij niets anders dan de aloude intake maar weer van stal te halen. In dit geval niet de intake van individuen, maar een intake van het team. De opdrachtgever zal dan een keus moeten maken uit teams van diverse aanbieders en op basis van met name subjectieve criteria zoals gevoel een inschatting en een keus moeten maken welk team het beste resultaat gaat opleveren.

Binnen agile is het verstandig om na ongeveer 20 procent van het totaal budget een oplevering te plannen. Dit geeft de organisatie de kans om het opgeleverde in gebruik te nemen en de voordelen te verzilveren. Voor inkoop is dat een ideale mogelijkheid om de kwaliteit van dienstverlening te evalueren om te bepalen of alles binnen de grenzen van redelijk vakmanschap verloopt. Zo niet is er nog alle kans om de gemaakte keuze te herzien en zonder al teveel schade het project een doorstart te geven. Hiermee krijgt inkoop een rol die moeilijker meetbaar is, maar waarschijnlijk meer waarde oplevert. Het inkoopproces helemaal objectief maken is een utopie die gezien de vele rechtszaken van ontevreden verliezers op dit moment ook niet gehaald wordt.

De grootste uitdaging ligt voor opdrachtgevers echter in het omarmen van agile, en daarmee verantwoordelijkheid nemen in de realisatie. De voordelen zijn duidelijk, maar je moet er wel wat voor doen. De wendbaarheid van de opdrachtgever zou wel eens de grootste succesfactor kunnen zijn, waarbij ook inkoop zijn wendbaarheid zal moeten tonen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4201610). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Goed artikel!

Vraag is waar inkoop voor staat. Als inkoop het beste voor de organisatie wil, zie ik geen belemmeringen dat ze na 20% van het totaal budget eventueel opnieuw een inkoopprocedure gaan starten. Maar inkoop bij de overheid is taai. Kan je (wil je?) na 20% een nieuwe Europese aanbesteding starten? Dat wil je veelal niet, gezien het zware procedurele gehalte. Dan is het toch zaak dat er een mantelovereenkomst is.
En ik heb gezien dat inkoop graag objectieve duidelijkheid wil. 10 potloden inkopen is checken of er 10 potloden afgeleverd zijn. En volledig beschreven resultaten van een vaste kwaliteit, tegen een prijs X en binnen tijd Y geeft de illusie voor inkoop dat ze het geleverde objecten kunnen ‘aftikken’. Zoals je aangeeft ligt de grootste uitdaging bij de opdrachtgevers in het echt omarmen van agile door de consequenties in eerste plaats uitwerken in de aanbesteding/inkoopprocedure.

Dus uiteindelijk moet ik als opdrachtgever gewoon een heel team inhuren op basis van inspanningsverplichting met een gegarandeerde minimale afname.

Maar ik ga ervan uit dat er toch wel iets wordt geroepen over de hoeveelheid werk die men verwacht te gaan verzetten? Of kan je daar nooit iets over roepen omdat "wijzigingen omarmt" worden?

En als er geen wijzigingen komen tijdens een agile-traject wordt alles opgeleverd? Of wordt er dan meer opgeleverd? Of wordt het goedkoper, met de factoren verschil?

Want het is nacalculatie toch? Het is toch gewoon uurtje factuurtje. Het is toch gewoon alle risico's bij mij, de opdrachtgever? Of zie ik iets niet.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×