Smidigavtale med bonuser fra DIFI

I januar lanserte DIFI ny versjon av sin SSA-S. En avtaleform som jeg flere ganger har karakterisert som “halvsmidig” – et  langsomt skritt i en riktig retning. Noe som sammen med en veileder kan hjelpe offentlige IT-innkjøp et lite skritt på veien mot noe bedre, men heller ikke mer… Potensialet til “helsmidig” er mye større.

Nå har de  introdusert bonuser. Ideen med slike mekanismer er jo å gi en aktør positive incentiver til å gjøre en bedre jobb enn de ellers ville gjort. Man setter målbare mål, samler data og utbetaler en belønning om aktøren oppfyller kriteriene.

Difi skriver: “Leverandøren får bonus hvis de leverer programvare med få feil, hvis de leverer før eller til avtalt tid, og hvis de leverer til avtalt kostnad eller lavere.”

Konsekvensene av incentiver er svært vanskelig å se på forhånd. IT-prosjekter er (svært) komplekse, sosiale systemer så vi må forstå kompleksitet og vi må bruke systemtenkning. I slike systemer vil ”alt påvirker alt” og legger vi  stimuli som bonuser inn i systemet, vil det få sideeffekter. Disse kan være negative. Vi har en del erfaring fra slike ordninger..

 

Bonus for få feil

Dette kan kanskje være OK. Dette er et opplagt gode, og fordi dette er et stort problem i mange prosjekter. Man tar seg ikke tid til å lage solid, korrekt kode som fungerer etter hensikten. Men det som selvsagt blir viktig er å definere “feil” på en slik måte at det blir mulig å telle disse på en fornuftig, objektiv måte, uten for mye skjønn. Når det står pengeutbetalinger på spill, kan vi ikke basere oss på skjønn. Den umiddelbare uønskede sideeffekten jeg kan se her er at leverandøren vil ha interesse av å skjule og bagatellisere feil.

Jeg er spent på hvordan dette skal praktiseres.

 

Bonus for å holde tiden

Dette er ikke OK! Mennesket er i utgansgpunktet dårlig til å estimere, vi er optimister og har vanskelig for å lære av feil (Les gjerne boka Thinking, fast and slow). Dessuten er software-utvikling komplekst, så uforutsette problemer kommer! Så det er normalt å komme på etterskudd. I en slik situasjon, når det er bonus knyttet til fremdrift, vil de som gjør jobben lett kunne ofre det gode håndtverket. Det gode håndtverket tar tid, men er veldig god økononi (for kunden) på sikt. Kunden har små muligheter til å måle og kontrollere den håndtverksmessige standarden som utføres.

Dette er selve oppskriften på å bygge opp teknisk gjeld!

 

Bonus for å levere under kostnad

Dette er ikke OK!  Å levere under avtalt kostnad blir lett uforenelig med ønsket om å lære og finne bedre løsninger mens man jobber. Hva skjer om leverandøren i dialog med brukerne finner ut at ting bør gjøres på en annen måte enn først antatt. Da blir det en vurdering om dette ekstraarbeidet kan komme i veien for bonusen.

Dessuten er dette på akkurat samme måten som bonus for rask utvikling en pådriver for å bygge opp teknisk gjeld. Det gode håndtverket koster tid og penger.

 

Bonus for å nå effektmål?

Om man på død og liv skal gi bonuser må dette knyttes til effektmål (verdi). Dette er uhyre krevende og fordrer stor modenhet både hos kunde og leverandør og man snakker om et regime som dette: http://www.flexiblecontracts.com/. Dette er spennende eksperimenter, men ganske uprøvd. Man bør uansett styre ved å gjøre kost/nytte vurderinger, men dette behøver ikke kobles til kontrakten.

 

Vi må behandle folk som voksne

Agile Manifesto (som definerer smidig) fokuserer på at det er menneskene som gjør jobben som er avgjørende. At du har dedikerte, motiverte folk som tett sammen med kunden finner løsninger underveis. At vi våger å stole på disse. Dette er ikke bare en “vakker tanke” for å gjøre utviklerne til lags. Dette er en nødvendighet hvis dette skal bli skikkelig bra! Vi klarer rett og slett ikke å kvantifisere produktivitet eller kvalitet godt nok. Så vi er henvist til den “kjedelige” virkeligheten at vi må behandle de som gjør jobben som voksne og stole på dem. Gi de ansvar og myndighet. En grad av autonomitet. På den måten får det det aller viktigste: Dedikerte folk som virkelig bryr seg om sluttresultatet.

 

Kunden må engasjere seg

Det finnes realistisk sett ingen andre modeller enn varianter av Time/Material om man virkelig ønsker innovasjon og læring underveis. Og når det gjelder risiko – så sitter kunden med den uansett. Kunden må “dessverre” engasjere seg og ha en viss kompetanse – man kan ikke distansere seg fra det. Jeg vil anbefale alle kunder som utvikler programvare jevnlig å

  1. Sørge for å ha noen egne  ansatte teammedlemmer (programmering test, design etc)
  2. Leie inn resten av kapasiteten på langsiktige kontrakter og bemann teamene med en miks av egne og konsulenter.
  3. Få på plass dedikerte, gode Scrum Mastere og Produkteiere – gjerne fra egne rekker.

På denne måten kan du få dedikerte team som er brennende opptatt av brukernes beste og som vil gjøre håndtverket grundig og bra så vi unngår å akkumulere opp teknsik gjeld.

2 Responses

Subscribe to comments via RSS

  1. Written by Hilde Kjølset, Difi
    on 14/03/2014 at 1:29 pm
    Reply · Permalink

    Vi har laget en artikkel som utdyper noen av de temaene du tar opp i blogginnlegget ditt og innlegget ditt på LinkedIn, se på http://webdesk.anskaffelser.difi.local/ikt/artikler/utdyping-av-sporsmaal-og-kommentarer-til-smidigavtalen-mars-2014

  2. Written by gamsjo
    on 15/03/2014 at 12:10 pm
    Reply · Permalink

    Hei Hilde,
    den linken fikk jeg ikke til å virke. Vil gjerne lese artikkelen:)

Subscribe to comments via RSS

Leave a Reply