tirsdag 19. oktober 2010

Lærende prosjekter, få suksess uten kravspesifikasjon!

På Prosjekt 2010 holdt jeg et foredrag om Lærende prosjekter. Du finner presentasjonen her: http://slidesha.re/dfRpea

Jeg har lyst til å kommentere presentasjonen noe.

Min argumentasjon knytter seg først og fremst til følgende argumenter:
  • Dersom du skal lage noe nytt for en bedrift, så får du ingen tydelige svar tidlig i prosjektet. Dette blir kalt taus(tacit) kunnskap av Nonaka.
  • Utover i prosjektet så vil du lære om hva som fungerer, og denne kunnskapen bør du benytte for å gjøre løsningen bedre. I henhold til Nonaka vil man få økt den eksplisitte kunnskapen (explicit) i løpet av prosjektets gang.
Gjennom mange år har IT bransjen levert prosjekter som har skuffet oppdragsgiveren (i henhold til en ny undersøkelse av Devoteam daVinci har 75% ikke oppnådd gevinstmålene). For de prosjektene som lanserer en fungerende løsning, viser undersøkelser fra Norge og utlandet at man bruker kun 40% av utviklede funksjoner. Dersom vi antar at alle funksjonene koster like mye å utvikle, så kan vi si at 60% av prosjektkostnaden går på å lage funksjoner som ikke er nødvendige!

Til tross for dette, så fortsetter vi å lage spesifikasjoner FØR vi starter utviklingen. Forskning og tilgjengelig empiri viser altså at denne framgangsmåten ikke gir ønskede resultater, og vil øke prosjektkostnaden unødvendig. Rundt omkring i Norge sitter det akkurat i dag mange prosjektledere og oppdragsgivere som skriver kravspesifikasjoner til fingertuppene blir såre. De som har pratet med brukerne, har fått tvetydige og usikre behov. Men dette stopper ikke analysefasen, da man må være tydelig i spesifikasjonen. Resultatet av analysefasen er dermed en liste over krav, ofte tatt fra funksjonslisten til mulige samarbeidspartnere. Man plukker de funksjonene man synes er kule, og ber underleverandører komme med pristilbud.

Konsulentselskapene elsker denne type kontrakter, da de vet at kunden vil lære underveis. Resultatet av denne læringen er endringsforespørsler fra kunden, noe leverandørene tjener meget godt på. Underprisede fastpriskontrakter er vanlig, da man vet at endringsmeldingene vil strømme inn i løpet av prosjektets gang.

Løsningen etter min mening er å erkjenne fakta: ved starten av prosjektet kjenner man løsningen og brukeratferden minst. Man bør dermed bestrebe:
  • Tidlig finne prosjektets hensikt, og suksessparametere 
  • Raskt å lansere en basisversjon (minimum marketable feature - MMF) av løsningen ut til testbrukere
  • Etablere en produkteier (med strategisk og teknisk forankring) som kan dra ut ideer og kunnskap av de involverte i løpet av prosjektets gang, og levere stadig bedre bestillinger til utviklingsteamet
Smidige prosjekter (som Scrum) med lanseringer hver 30. dag passer som hånd i hanske inn i denne lærende prosjektfilosofien. Man bør sette opp absolutte tidsfrister, og timeboxe leveransene. Resultatet vil bli prosjekter som leverer nytte til organisasjonen i større grad enn fossefallsprosjekter, under sterkere reell kontroll på tid og kostnad.

Derimot vil man ikke kunne garantere at alle funksjonene som man hadde sett for seg ved starten kan lanseres, noe som uansett ikke er så farlig for de som skal benytte løsningen. Undersøkelser viser jo at de ikke ville ha benyttet de aktuelle funksjonene uansett! I stedet vil man kunne få nye ideer som dukker opp i løpet av prosjektets gang som implementeres raskt, og som har stor reell nytte for brukerne.

Eksempel på et slikt prosjekt er Innovasjon Norges søkemotorprosjekt hvor jeg fungerte som produkteier. Store og små ideer ble tatt tak i og implementert i løpet av prosjektets gang, og resultatet er en løsning de ansatte faktisk benytter og liker! Grunnet tidlig lansering kunne vi ta tak i tilbakemeldinger fra brukerne og drift, som førte til en mer stabil løsning som sannsynligvis er rimeligere å drifte enn ved “big-bang” lanseringer.

Det eneste man må gjøre, er altså å frigjøre seg fra troen at man i en tidlig fase er i stand til å:
  • Forutse all kompleksitet som vil dukke opp
  • Forstå teknologien godt nok
  • Forutse brukerbehovene
I tillegg må man få juristene til å lage kontrakter hvor man kan få størst nytte ut av hver investerte krone, i motsetning til i dag hvor man ber om å få levert noe man slettes ikke er sikker på vil bli benyttet.

Ingen kommentarer:

Legg inn en kommentar