Ida tar sin idé umiddelbart ut i markedet, og hun kommer til å vinne over det store prosjektet, som jobber grundig frem mot en stor lansering. Mot alle odds vil noen si. Ren flaks sier andre. Stikk motsatt, sier vi.

Det er en utbredt oppfatning at en god idé bør utvikles ordentlig før den lanseres. Sluttproduktet må ha en skikkelig finish når den møter et marked med lite rom for tilgivelse. Førsteinntrykk er alt, ikke sant?

I spillindustrien erfarer man at en dårlig førsteutgave av et spill kan medføre at senere, forbedrede versjoner flopper. Ikke bare nekter kundene deg et andre forsøk, de sprer også negative meninger om skuffelsen de opplevde med den første versjonen. Spillselskaper sørger derfor for å gjøre seg flid før de slipper et produkt, og da er det vel nærliggende for andre bransjer å anta at det samme gjelder dem?

Samtidig er det bekymringsverdig normalt å høre om nedlagte IT-satsinger. Noen prosjekter flopper i møtet med markedet, mens andre legges ned før de ser dagens lys. Verst av alt er det at som regel står talentfulle, kompetente og dyktige personene bak prosjekter som feiler.

Det er finnes ingen garantier for å lykkes, selv om vi er dyktige i vårt fag eller har en god idé. Ei heller gir kombinasjonen av faglig dyktighet, en god idé og et stort budsjett noen garanti. Tvertimot er dette den største risikosonen av dem alle.

På vei til markedet

La oss dikte opp et eksempel, ved å se for oss en fiktiv forretningsidé. Den kommer fra den nordnorske reiselivsnæringen, som ønsker seg en tjeneste som samler og presenterer reisetips, tilbud og produkter i salg fra regionen. Her vil brukerne kunne bestille pakkereiser, få tips om tur-, jakt- og fiskemuligheter, kjøpe raffinerte matprodukter som tørrfisk, fenalår, multesyltetøy osv. Alt på et sted!

Vår forretningsutvikler heter Ida, og hun er faktaorientert. Hun har gjort en markedsanalyse, brukt fokusgrupper og andre virkemidler for å skape seg et inntrykk, men innser dette fortsatt er antagelser. I tillegg har hun erfart at det kan være stor forskjell på hva du hører i en fokusgruppe, og hva du hører fra betalende kunder.

Hun vil derfor ut i markedet så fort som mulig, og bestemmer seg for å begynne med en tur-blogg. (For å gjøre vår lille anekdote ytterligere spennende, ser vi for oss at en større reiselivsaktør samtidig starter opp et utviklingsprosjekt for det som kan bli en konkurrerende tjeneste. Utviklingsdelen av prosjektet er estimert til å ta ca ett år.)

Turbloggen til Ida har et enkelt konsept: Den omtaler skjulte “perler” – turtipsene bare noen få kjenner til. Den begynner med å beskrive turen opp til Håtinden i Lofoten, og har i tillegg et par annonser til noen utvalgte, spesielle kvalitetshoteller, for eksempel Edvardas Hus på Hamarøy. Bak sceneteppet har hun sørget for å integrere et standard analyseverktøy slik at hun har kontroll på trafikken til bloggen, og for eksempel kan se hvilke annonser som blir trykket på, hvem som lenker til bloggen, og så videre. I tillegg har hun gjort det svært raskt å gjøre endringer på bloggen i produksjon. Noen enkle, automatiserte tester passer på at alt fungerer som det skal.

Ida sørger også for at annonsene vises i to forskjellige versjoner. De har samme innhold, men forskjellig utforming, og hun ønsker å finne ut hvilken av dem som får flest klikk.

Brukerne på sin side opplever en helt vanlig blogg med annonser. Eneste forskjell fra andre blogger er at annonsene lenker til virkelig gode tilbud, og at blogginnlegget gir verdifull informasjon – iallefall for de som hadde tenkt seg på fottur i Nord-Norge.

Fremfor å utvikle noe mer, tar hun seg nå tid til å promotere bloggen. Hun er aktiv på andre reiselivsfora, legger inn kommentarer som lenker til bloggen sin og twittrer. Kanskje skaffer hun seg tilogmed omtale av en etablert blogger, eller Turistforeningen. Hun skriver noen flere innlegg med flere turtips.

Tørrtrening med tørrfisk

Neste steg er å bytte ut én av annonsene til overnatting, og istedenfor promotere et tørrfiskprodukt hun ønsker å selge. Brukeren går da til en annen side på “bloggen”, der et enkelt formular innhenter de nødvendige opplysninger. Formularet lages på samme måte som annonsene, med to utforminger som vises om hverandre (men hun sørger for at samme bruker alltid får se samme versjon av formularet). Det tar henne to dager å utvikle en enkel integrasjon med PayPal, slik at hun kan ta betalt. Siden hun foreløpig bare selger ett produkt, vil innsending av formularet sende henne en epost med informasjonen som ble fylt inn.

Etter nok en uke, analyserer hun dataene – faktaene – hun har samlet. Det viser seg at siden for salg av tørrfisk får flest besøkende med klar margin. Det som overrasker henne mer er at mesteparten av trafikken inn til denne siden ikke kommer fra bloggen. Analyseverktøyet røper at den kommer fra Google-søket “tørrfisk salg”.

Hun bestemmer seg for å legge ut et produkt til, men denne gangen uten annonse fra bloggen. Istedenfor optimaliserer hun nettstedet sitt, slik at søkemotorene indekserer og presenterer den på best mulig måte. I mellomtiden merker hun at salget begynner å øke, og at det snart vil være vanskelig å betjene den nokså manuelle prosessen med epost. Hun implementerer derfor en enkel database-tabell, der bestillingen legges inn. På den måten kan hun nå benytte et standardverktøy for databaser til å hente ut bestillingsinfo.

Etter samtaler med noen lokale kjøpmenn, som tenner på idéen hennes, bestemmer de seg for å legge ut et tilbud som er virkelig godt. En kjempe-deal, som også anbefaler et annet produkt til vanlig pris. Begge deler selger bra, og hun blir overrasket over at mesteparten av trafikken kommer rett fra Google. Hun bruker noen av pengene hun har tjent på salget til å legge ut Google-annonser for å drive inn enda mer trafikk.

På dette tidspunktet har konkurrenten skaffet seg en leverandør, og de jobber iherdig med å spekke opp tjenesten som skal lages. Wireframes, grafisk design og konseptbeskrivelser produseres, mens utviklerene jobber med å sette opp et standardløsning for nettbutikk, og en annen standardløsning for bestilling av reiser (de skal integreres på et senere tidspunkt). Først skal de sørge for at forsiden til tjenesten får den riktige finish, der flotte bilder av storslått nordnorsk natur ruller i en imponerende Flash-animasjon.

Intetanende om konkurrentens ambisjoner jobber vår forretningsutvikler iherdig videre. Hun har kommet i dialog med noen av brukerne, gjennom kommentarfunksjonaliteten hun har lagt til bloggen, og flere av dem har begynt å etterlyse noen forskjellige, enkle funksjoner. De blir svært entusiastiske når hun få dager etter en etterlysning har implementert en enkel førsteutgave av det de ba om. De synes selvfølgelig det er gøy å hjelpe henne forme den videre. Hun får også mye skryt for den enkle brukeropplevelsen, der man kan finne produktet man ønsker seg, og bestille det ved hjelp av få klikk. Flere av de som har gått turen opp til Håtinden har begynt å anbefale bloggen blant sine venner. De begynner igjen å anbefale tjenesten videre, og tilbakemeldinger, ønsker og ros strømmer inn. Hun begynner å se behov for å bygge opp et lite utviklingsteam – én utvikler om gangen.

Antagelser er roten

Denne historien kunne fortsatt, men jeg lar det være opp til leserne å tenke seg hvordan situasjonen ville vært for vår forretningsutvikler når konkurrenten hennes lanserer sin tjeneste året etter (hvis de kommer i mål på estimert tid). Om du ikke tror hennes fremgangsmåte er overførbar til dine omgivelser – kanskje har du rett – så må du iallefall være enig i at hun ikke baserer seg på flaks.

Det gjør derimot alt for mange. De lar seg forføre av en god idé og føler seg deretter forpliktet til å ha alle svarene på forhånd. Dette gir mange utfordringer på veien frem mot lansering. Alle involverte danner seg etterhvert egne oppfatninger av hva som er viktig. Det blir utfordrende å holde fokus, og det oppstår mange misforståelser mellom teknologer og forretningsutviklere. Ingen av dem har harde fakta, som kan stoppe de evinnelige diskusjonene. I dette spekulative klimaet har de færreste tid til å holde i “myke” aspekter, som brukeropplevelse og kundedialog.

Vi tror det er mulig for alle bransjer å rasjonalisere bort gevinsten av tidlige tilbakemeldinger. Problemet er at de som vinner idag gjør det stikk motsatte. Programvare kan – og bør – forandres kontinuerlig. Du må anerkjenne at selv med lang erfaring og høy kompetanse har du intet mer enn antagelser helt frem til den dagen du får betalende kunder. Du må innse at kundene ønsker å være delaktige i utformingen av ditt produkt. Ikke bare detaljene – men hele idéen i seg selv. Du må forstå at vil du investere med IT, så må du bruke IT til å investere.

Ikke alle som satser på flaks feiler. Det ligger i begrepets natur. Noen vinner alltid i lotto. Selv har jeg aldri opplevd det. Verken å vinne i lotto, eller vinne med et prosjekt som ikke oppsøker virkeligheten.

Har du?

Visste du at programvareutvikling kan betale for seg selv?

De fleste private vekstbedrifter i Norge er små og mellomstore. De bruker som oftest en kombinasjon av standard programvare. Noen har også skreddersømløsninger for spesielle behov.

Allikevel lurer mange på hvordan IT-bruken deres egentlig fungerer. Kunne vi jobbet smartere? Hvor lønnsom ble forrige IT-anskaffelse? Er vi tilstrekkelig forberedt på tidene som kommer?

Som IT-konsulentselskap retter Iterate seg mot kunder som trenger ikke-standard programvare, eller som trenger å få forskjellige standardprogrammer til å snakke bedre sammen. IT-utviklingsprosjekter er kostbare, og de innebærer høy risiko, fordi kunden som regel må investere en betydelig sum lenge før prosjektet blir verdiskapende.  Slik skreddersøm er derfor vanligst i store organisasjoner.

Hva gjør da små og mellomstore bedrifter med behov for slike prosjekter?

I samarbeid med nasjonalt og internasjonalt fagmiljø, har vi laget en metode for å utvikle programvare iterativt. Vi kaller metoden Selvfinansierende IT, og målet er å redusere investeringen, uten å redusere muligheten for verdiskapning.

Eksperimenter viser at barnehagebarn som får 20 stenger spaghetti, litt hyssing, teip og en marshmallow, klarer å bygge et tårn høyere enn det toppledere, som får sammen oppgaven, klarer. Årsaken er at barn umiddelbart starter byggingen av tårnet, og jobber stegvis frem til tiden er ute.

Slik jobber vi også, og det er derfor vi heter Iterate. En iterasjon varer noen uker, og leverer programvare som gir din bedrift verdiskapning. Pengene du tjener på programvaren kan du bruke til å finansiere neste iterasjon.

Vi levererer slike iterasjoner til kunden er fornøyd. Dette gir lavere risiko og raskere inntjening. Erfaring viser også at det gir dere bedre løsninger. Hvorfor? Fordi kunden får påvirkningskraft underveis. Fordi kunden lærer underveis. Fordi vi lærer underveis.

Dermed blir det også mulig for vanlige bedrifter å utnytte IT til å skape noe nytt.

På samme måte som en fjellklatrer må en utvikler ofte utfordre sine egne grenser for å komme fram til målet. Men det er vanskelig å nå toppen hvis klatreren ikke stoler på sikringen. Der fjellklatrere bruker tau og bolter, kan utviklere stole på automatisert testing.

Et utviklingsprosjekt handler om å innføre ny funksjonalitet. Jo større og mer uoversiktelig systemet er, desto mer skremmende kan det være å innføre ny funksjonalitet.

Utviklere kan bli redde for å innføre nye feil – enten i selve koden de leverer, eller i form av følgefeil som kan dukke opp helt andre steder. Frykten kan gå utover leveransefart og lyst til utprøving av nye ting som kan øke kvaliteten.

Endringsvillighet

Utviklingsprosjekter kan lande i en situasjon hvor testing av ny funksjonalitet tar for lang tid.  Konkurransedyktighet innenfor programvareutvikling handler om å raskt kunne tilpasse seg endringer. Forretningsmuligheter kan forsvinne fordi man ikke klarer å levere raskt nok.

Innenfor programvareutvikling er testing av løsningen prosjektets sikkerhetsutstyr. Sikkerhetsutstyret bør være i orden og enkelt og bruke for at de som gjennomfører prosjektet skal kunne yte maksimalt.

Continue reading

I løpet av det siste året har jeg satt meg inn i Beyond Budgeting. Blant annet har jeg lest boken til Bjarte Bogsnes, som jeg fant meget interessant. Når jeg leser prøver jeg å trekke paralleller til IT-bransjen. Ved å sammenligne budsjetter med estimering fikk jeg en liten ekstra innsikt som jeg deler her.

I Beyond Budgeting omtaler man et av problemene med det tradisjonelle budsjettet – det er på en og samme tid både målsetning, forespørsel om ressurser og estimat. Ideen i Beyond Budgeting er at disse bør deles opp i tre separate tall:

1. Estimatet – med det vi vet nå tror vi at vi kommer til å bruke så mye penger
2. Målet – vi mener at det bør være bedre måter å gjøre dette på, dette er vår ambisjon
3. Forespørsel om ressurser – estimatet er bare et estimat, vennligst sett av så mye penger til dette formålet

Her er målet lavere enn estimatet, og estimater er lavere enn ressursforespørselen. På denne måten får man utfordret estimatet, på samme tid som man ikke trenger å gå til ledelsen for å be om mer penger selv om man bommer noe på estimatet.

Parallellen jeg trekker er til estimering i IT-bransjen. For et gitt prosjekt eller en bestemt iterasjon blir vi bedt om å estimere tid- og ressursbruk. Kunne vi med fordel ha delt dette oppi flere ulike elementer, akkurat som for budsjettene i Beyond Budgeting?

I så fall ville selve estimatet ha vært vår beste gjetning. Vi kunne satt oss selv et ambisiøst mål, slik at vi kunne utfordre oss selv og finne kreative løsninger. Om estimatet skulle slå feil har vi allikevel litt ekstra å gå på, så slipper vi canossagang til den som sitter på ressursene. Estimater er jo tross alt bare estimater.

I den siste tiden har jeg hatt glede av å delta i en tankesmie om bruk av Lean i IT-prosjekter. I tankesmien har det deltatt både ingeniører, advokater og økonomer. Ideen har vært å få ulike perspektiver på hva som er de praktiske utfordringene i slike prosjekter, både fra leverandørsiden, kundesiden og det juridiske. I smien har vi hatt med Iterate fra leverandørsiden, Belief som representant fra kundesiden og Bull & Co fra juridisk.

Arbeidet har bestått i å sammenligne de tradisjonelle prosessene med de arbeidsmåtene Lean foreskriver. På den måten har vi klart å tegne et kart som beskriver veien frem til å utnytte potensialet til Lean i dine IT-prosjekter. Hva er potensialet til Lean? Riktig utnyttet kan det oppsummeres på denne måten:

• Lavere investeringer og dermed lavere risiko
• Tidligere Return-On-Investment og dermed mer lønnsomme prosjekter
• Bedre feedback og dermed bedre løsninger for sluttbrukeren

Arbeidet med dette skal resultere i et veikart fra tradisjonelle til innføring av Lean i organisasjonen. Det vil være fokusert på utfordringer fra de ulike ståstedene i tankesmien. Det ser ut til å bli i form av et frokostseminar torsdag 8. oktober 🙂 Følg med!

Minimum marketable features and incremental funding are used to partition the functionality of a computer system into units that are capable of delivering business value independently. By organizing a development project around MMFs and their internal dependencies, it is possible to have partially self-funding projects: As an MMF is completed, the business value that is saved or generated as it goes into production is used to fund the development of subsequent MMFs. Hence, we lower the up-front investment of our projects, and we reduce the development risks by continuously deploying functionality into production.

In short, we may say that using MMFs provide a financial model for lean thinking in software development projects. (For more info on this, refer to the excellent introduction given in “Software By Numbers” by Mark Denne and Jane Cleland-Huang, Prentice Hall, 2003).