3. Prosjektstyring

Dette kapitlet handler om metoder for å styre et prosjekt fra start til mål.

• Smidig utvikling
• Lean startup
• Google sprint

3.1. Handlingspunkt

• Dere må ha god prosjektstyring. Hvis ikke, kan prosjektet ende opp som en uforløst idé og dere blir uvenner for livet.
• Dere må ha en prosjektleder. Noen må ta ansvar for å tenke på alt samtidig. Hvis du er en god prosjektleder skal du ikke regne med å vinne prisen som årets mest populære medarbeider. Men dere kommer i mål.
• Dere må ha struktur på arbeidet, legge press på dere selv, respekt for deadlines, og oppsplitting av oppgaver så de blir lettere å gjennomføre.

3.2. Vær leder, ikke administrator

Da jeg var redaktør i Ekstra Bladet i Danmark var jeg ofte frustrert over mangelen på fremdrift på prosjekter jeg ventet på skulle nå målet. Det var dyktige, ryddige, systematiske og samvittighetsfulle prosjektledere på alle prosjekter. Men dessverre var det så mange prosjektledere og så få utviklere og designere at det var ekstremt god kontroll på prosjektene, men også alt for lite fremdrift.

Vi har alle forskjellig personlighet. Noen er introverte, andre ekstroverte, noen er strukturerte og ryddige, mens andre klarer knapt nok finne et dokument som ligger i en mappe på PCen selv om de er supereffektive på andre områder. Når vi skal drive gjennom et innovasjonsprosjekt trenger vi en bred sammensatt gruppe, der vi trekker det beste ut av hver persons egenskaper og kompetanse.

Våg å bli upopulær

Prosjektlederen skal sørge for fremdrift, legge til rette for at det tas beslutninger og også åpne for diskusjon der det er naturlig. Men først og fremst sørge for at deadline følges og at leveransene kommer til avtalt tid. Derfor bør jobben løses av en som er bekvem med å være tydelig og ganske uredd for å bli upopulær i korte øyeblikk. Men husk at du er "leder", så du skal lede, ikke sjefe.

De beste prosjektledere jeg har jobbet med, har vært avgjørende for at vi lykkes. De dårligste har ofte vært fantastisk gode på regneark og presentasjoner, på kakebestillinger og kostnadskontroll. Men de har ikke vært prosjektledere, de har vært prosjektadministratorer og dels latt teamet bli altfor involvert i alle beslutninger. Eller egentlig har de sørget for at det ikke er blitt tatt tydelige beslutninger.

Dels har de brukt mer ressurser på å rapportere presist og elegant til overordnede enn til å forstå når et problem kan hindre effektiv fremdrift. I beste fall bør de forstå og løse problemet før noen andre ser at det vil oppstå.

Tillit og selvtillit

Selvtillit - og tillit fra kolleger og overordnede - er ofte mangelvare. Men en prosjektleder som hverken har selvtillit eller tillit, kan være hovedgrunnen til at et prosjekt går i dass. Og hvis du ikke har evnen til å motivere kollegene til fremdrift med ord når det virkelig butter, bør du vite om det er frukt eller god kaffe som skal til for å skape bedre stemning.

Motivasjon er sjelden et problem i en gruppe som har fått mulighet til å skape noe de selv har tenkt ut. Men hvis den faller, tenk som en dyktig mor som ga deg lyst til å gjøre ferdig leksene og spise opp spinaten, før du fikk lov til å kose deg med det du hadde mest lyst til.

Jeg er opptatt av at prosjektlederen skal være en aktiv pådriver, en som virker positivt inn på teamet og som bidrar til at ting er på sporet, men som ikke skal forsinke prosessen med unødige forstyrrelser.

3.3. Hva er prosjektstyring?

Den globale databransjen som utgår fra Silicon Valley er avhengig av effektiv prosjektstyring, og det har derfor oppstått mange gode metoder. Her skal vi presentere SCRUM, lean startup og Google Sprint. De er vanlige å bruke i internasjonalt gründerskap, det er lett å finne metodebøker og nettressurser, og de som skal utvikle nye produkter i Norge trenger å forstå dem. Studentprosjekter i TekLab har blitt styrt med smidige metoder over lengre tid, og vi ser at de fungerer godt. Alle som vil drive med innovasjon bør kunne snakke dette internasjonale “språket”.

Verdiforslag. Målsetningen med et prosjekt kan kalles et "verdiforslag" eller på engelsk en «unique value proposition». Verdiforslaget for vår håndbok er som følger:

"Her finner du alle de metodene du trenger for å skape et nytt produkt og bringe det ut på markedet. Vår bok er gratis tilgjengelig på nett og kan brukes i alle slags situasjoner".

Et verdiforslag kan gjerne formuleres som et slagord. På 1970-tallet hadde Coca Cola stor suksess med slagordet “Have a Coke and a smile”. Verdiforslaget beskriver fordelene med deres foreslåtte løsning, hvilken verdi den vil kunne ha for brukerne, og hva som skiller dere ut fra andre tilbydere av nye løsninger. God prosjektstyring vil øke prosjektets sjanse til å lykkes med dette.

Vårt smidige drømmelag

Før vi presenterer de handlingene som skal gjøres når man styrer et prosjekt, må vi introdusere de funksjonene som trengs i gruppen. Vårt smidige drømmelag har sju oppgaver som vi tar for oss i denne håndboken. Hvert av hovedkapitlene forklarer de handlingene som må utføres for å løse hver av oppgavene.

1. Prosjektleder holder i alle trådene og styrer retningen på utviklingen.
2. Researcher skaffer innsikter ved hjelp av systematiske metoder.
3. Interaksjonsdesigner lager den tekniske prototypen.
4. Innholdsdesigner lager eksempelinnhold til prototypen.
5. Brukertesteren (UX-ansvarlig) finner ut hvordan folk reagerer på prototypen.
6. Forretningsplanleggeren lager en plan for verdiskaping og -forvaltning.
7. Pitch-ansvarlig formidler verdiforslaget i offentlige sammenhenger.
8. Pivot-varsler. Alle har ansvar for å vurdere om prosjektet bør skifte kurs eller avsluttes.

Gruppen bør ikke bestå av like mange personer som denne listen består av, for da ville det blitt krevende å være prosjektleder. God prosjektstyring forutsetter at lagmedlemmene er i stand til å metoder og målsetninger ettersom prosjektet utvikler seg. Det er vanlig at en person påtar seg flere forskjellige funksjoner, og de kan dessuten ha ulik tyngde i ulike fase av prosjektet. Innsiktsarbeid er for eksempel særlig viktig i begynnelsen og pitching er særlig viktig mot slutten, og en person kan derfor skrifte mellom dem over tid. Det vil ofte være tekniske utviklere med i teamet, og de jobber vanligvis tett på interaksjonsdesigneren.

Smidige metoder

Smidig prosjektstyring er viktig i databransjen. Smidig er en norsk oversettelse av det engelske “agile” som blir brukt i Silicon Valley og den globale databransjen. Smidige metoder gjør at prosjektgruppen kan dyrke fram gode, realiserbare idéer under usikre vilkår. Det handler om å utforske nye muligheter og ta risiko med ressursbruken, men samtidig gjøre det på en mest mulig driftseffektiv måte. Prosjektstyring handler om å være i fleksibel nok til å finne ukjente nye verdier, men også disiplinert nok til ikke å sløse bort ressursene i forsøket.

I mange tiår foregikk teknisk utvikling med en fremgangsmåte som ble kalt “fossefallmetoden”. Denne ble brukt til store prosjekter hos firmaer som IBM eller Norsk Data, og var preget av en sentralstyrt prosess der ledere og adminstratorer holdt øye med utviklingen. Prosessen beveget seg fremover i faste steg, og det var vanskelig å gjøre forandringer underveis (Stellman og Greene 2015, s. 18).

Modell 4: Den tradisjonelle fossefallmetoden for prosjektstyring. Smidige metoder er et alternativ til denne. Basert på Stellman og Greene (2015), s. 18.

Fossefallmetoden dreier seg om å følge en plan. Den forutsetter at man vet alt som trengs ved slutten av prosjektet allerede når man begynner. Dette fungerer bare i en perfekt verden der firmaet har store ressurser og makt til å tvinge markedet til å akseptere løsningene. I virkelighetens verden er firmaer ofte små start up-initiativ, og vilkårene for prosjektet såvel som målsetningene forandrer seg underveis. Fossefallmetoden er for rigid til å fungere godt i et stadig mer start up-preget marked (Stellman og Greene, 2015, s. 19), og brukes i liten grad.

Smidige metoder er en samlebetegnelse for en rekke beslektede tilnærminger som har til felles at de avløser fossefallmetoden, og legger vekt på å kunne reagere godt på ufortusatte forandringer. Utviklere fra amerikanske fagmiljøer har formulert et "Manifest for smidig programvareutvikling" (2001) som blir mye brukt. Her skriver de:

"Vi lært oss å verdsette følgende:

• Personer og samspill fremfor prosesser og verktøy
• Programvare som virker fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• Å reagere på endringer fremfor å følge en plan"

Denne måten å tenke på er helt sentral for vår tilnærming til design, entreprenørskap og innovasjon. Den gjelder ikke bare for programvare i streng forstand, men for alle prosjekter der man vil lage et nytt produkt.

Smidige metoder har et viktig fellestrekk, nemlig at man må holde orden på de handlingene som skal gjøres i prosjektet. Selv om virkemiddel og målsetninger kan forandre seg, trenger man til enhver tid god kontroll over situasjonen. Dette kalles “arbeidsflyt” og styres med det som kan kalles et “oppgavebord” (Stellman og Greene, 2015, s. 37).

Modell 5: Et eksempel på et oppgavebord, basert på Stellman og Greene (2015), s. 37.

Et oppgavebord holder oversikten over alt som skal gjøres i prosjektet. Figuren viser en vanlig måte å gjøre det på, der relevante brukerhistorier samles lengst til venstre, og så har man tre viktige kolonner for det som må gjøres, det som pågår akkurat nå og det som er ferdig. Denne strukturen er både enkel og kompleks samtidig. Det visuelle systemet hjelper prosjektlederen å føre oversikt over daglige, ukentlige og månedlige oppgaver, pluss at man kan presisere hvem som skal gjøre hva. Samtidig åpner denne strukturen for en stadig større kompleksitet ettersom prosjektet utvikler seg. Teamet kan for eksempel forandre prioriteringen av oppgaver og flytte ansvaret til andre medarbeidere. Mange prosjekter bruker digitale verktøy som Trello for å holde orden på arbeidsflyten.

Lean startup

Den metoden som kalles “lean startup” er basert på prinsippene for smidig utvikling. Fail fast! og Fail forward!, sier lean-entusiaster. Disse to slagordene peker på kjernen i lean startup. Dette er en metode for rask idéutvikling og validering i markeder der det meste er usikkert, slik som mediebransjen. Prosjektstyringen skjer på basis av rask testing av nye ideer til et design. Lean-metoden ble utviklet av den amerikanske entreprenøren og forfatteren Eric Ries (født 1978), og presenteres i boken The Lean Startup (2011).

Designere og innovatører forutsetter at noen vil være interesserte i å bruke produktet de lager, og dette kaller Ries ”leap-of-faith”, s. 81. Alt avhenger av at produktideen er god, men hvor god er den faktisk? Dette må du finne ut raskt, seier Ries. En startup har dårlig tid, begrenset med kapital, og andre begrensninger som gjør at tid er din mest kostbare ressurs.

Klokka går! Det gjelder å finne ut om du kommer til å feile før du har brukt for mange ressurser. Lean-metoden dreier seg derfor mest av alt om å dobbeltsjekke hvor troverdige og realistiske disse “leap-of-faith-assumptions” er (Ries, s. 94). Dere må finne ut om idéen er så god som dere synes selv, og hvis den ikke er det må dere skifte retning på utviklingen.

Bygge, måle, lære

Lean startup-metoden er knyttet til slagordet “bygge, måle, lære”. Det Ries kaller validert læring krever en systematisk gjentakelse av utviklingsarbeidet. Han kaller dette ”the build-measure-learn feedback loop” (Ries, s. 22). Startup-selskaper eksisterer ikke bare for å lage ting, men også for å bygge opp en bærekraftig forretningsplan. Dere kan lære hvor god planen er ved å kjøre hyppige eksperimenter som gjør det mulig for dere å teste hver eneste lille forutsetning i visjonen (Ries, s. 9).

Modell 6: Bygge-, måle- og lære-sløyfen, basert på Ries (2011), s. 75.

1. Bygge. Utviklingsteamet må bygge et testprodukt eller “minimum viable product” på engelsk. Tenk stort, men bygg smått, sier Ries. Det kan være mock-up, skisser, low-fidelity, wireframes, video (s. 98), etc. Ikke bruk arbeidstid på å overkonstruere produktet. Det er stor fare for at dere sløser med verdifull arbeidstid. Lag MVPen for å bli testet på early adopters. De er interesserte nok til å tåle det.
2. Måle. Dere må måle de potensielle brukernes interesse. Dere må finne ut hvem som er den antatte målgruppa for produktet. Kom deg ut av bygningen, sier Ries. Det er viktig å teste MVPen med reell brukeradferd, og ikke spørre seg hypotetiske spørsmål om framtidig bruk. Hvilke kundemeninger bør teamet egentlig lytte til? Få tak i 3-4 personer som passer i målgruppen og snakk med dem. Gå gjennom tilgjengelig statistikk eller utfør spørreundersøkelser. Kundegruppen kan endre seg underveis, og da må målingene gjøres på nytt.
3. Lære. Dere må lære av funnene fra målingene. Ries sier at validert læring er hovedresultatet fra lean-metoden, enten den forteller om suksess eller fiasko. At læringen er validert betyr at den er basert på empiriske data som blir tolket systematisk slik at andre ville kunne trekke de samme konklusjonene. Innsiktert om prosjektets nåværende og fremtidige forretningsmuligheter blir bare verdifulle hvis de er troverdige. Dere må vise at dere har funnet ut hva kundegruppen virkelig ønsker, ikke hva de sier at de ønsker eller dere selv håper at de ønsker.

Det er viktig å merke seg at Ries kaller denne prosessen en “feedback loop”. Et annet ord som blir ofte brukt er “iterasjon” eller gjentakelse. Bevegelsen fra å bygge til å teste og lære kan gjentas mange ganger. Tenk bare på et gigantprosjekt som Microsoft Office-pakken. Den har gått gjennom hundrevis av iterasjoner der utviklingsteamet hele tiden prøver å forbedre ting i produktet.

Google Sprint

Google Ventures’ Design Sprint organiserer prosjektet på en måte som skal hjelpe gruppen å finne svar på de alle de viktigste spørsmålene i løpet av en arbeidsuke. Utviklingsprosessen har fem steg blant annet for at de skal kunne gjøres på hver av ukedagene fra mandag til fredag, men også fordi fem steg er vanlig i samband med innovasjon. Det er lett å se at Google Sprint minner om femstegsmodellene for respektive design og entreprenørskap som ble diskutert i forrige kapittel. Sprint er altså ikke en original metode, men et “greatest hits” av gode råd basert på smidige metoder for forretningsutvikling, psykologisk atferdsvitenskap og designtenking (Knapp et.al. 2016: 9).

Modell 7: Sprintmetodens fem steg basert på Knapp et.al. (2016), s. 17.

De fem stegene som vises i modellen kan spesifiseres slik:

1. Mandag. Lag en oversikt over problemet og velg noe konkret som dere fokuserer på.
2. Tirsdag. Skissér ulike, konkurrerende løsninger på problemet på papir. Gjør prosessen så enkel som mulig.
3. Onsdag. Ta en beslutning og gjør idéene om til en hypotese som kan testes.
4. Torsdag. Hamre ut en realistisk prototype.
5. Fredag. Test prototypen med mennesker utenfor teamet.

En sprint fungerer ekstra godt hvis teamet har en “beslutter” som tar de viktigste beslutningene om fremdriften (på engelsk “decider”). Beslutteren trenger ikke å være den samme personen som er prosjektleder, for prosjektledelse handler mest av alt om effektiv drift. Man kommer ikke nødvendigvis raskt videre ved hjelp av demokratiske avstemninger i gruppen, og det kan være mer effektivt at noen har makt og troverdighet til å ta en beslutning.

I prosjekter som utføres for en oppdragsgiver er det lett å velge denne rollen, for da må det være en person fra firmaet som har bestilt produktet. I studentprosjekter må man ofte velge en av prosjektmedlemmene til “beslutter”. Det viktigste, i følge Knapp et. al. (2016) er å ha velge en ansvarlig og engasjert person til å ha denne rollen (s. 31). Uten en beslutter vil prosjektet kunne sprike i alle retninger.

3.4. Studentenes erfaringer

Gode prosjektstyringsmodeller starter med et organisert og motivert team. Men på studentprosjekter har man ikke mulighet til å styre hvem og hvor mange man skal være på et team. Det blir vanligvis bestemt av kursledere ut fra praktiske forhold som antall studenter på kurset og behovet for kjønnsbalanse. For å gjøre vondt verre, så er det sånn i arbeidslivet også! Desto viktigere er det å ha et bevisst forhold til prosjektets gang og bruke gode metoder for prosjektstyring.

Mange har ulike erfaringer med gruppearbeid på skolen, og noen grøsser bare av tanken. Det som er gøy med innovasjon, er at dere er ikke bare en gruppe, men et team med eksperter! Eller, om ikke dere ennå ikke er eksperter så blir dere det raskt. Mot slutten av et prosjekt har dere mest sannsynlig lært masse, både om design og entreprenørskap, men også om dere selv, hvem dere er i et team, og hvordan samarbeide effektivt. Om prosjektet er skikkelig dårlig organisert, lærer man masse av det også!

I Vink-prosjektet var vi et team på syv, og det er veldig mange designere på ett prosjekt. Et team på syv kan gjøre mye arbeid på kort tid med god prosjektstyring. Men det motsatte kan også skje. Uten særlig struktur og tydelige roller kan slike prosjekter bli et stort kaos. Her er noen ting vi har tatt med oss, både fra Vink-prosjektet og andre prosjekter, som er nyttig for alle som skal sette i gang med innovasjonsprosjekter.

Lag et målrettet team

Det er lett å undervurdere viktigheten av roller i et team. Dette er noe bedrifter kan tape mye tid og penger på når ikke ansvarsområdene blir fordelt skikkelig. “Alt mulig”-rollen fungerer dårlig. Tenk over hvor dere kan effektivisere arbeidet eller gjøre det lettere for dere selv. Kanskje dere trenger en møteleder som sørger for at møtene har fremdrift og at alle holder seg på sak? Eller kan en ha ansvar for å lage en liste med konkrete mål for hver uke, som teamet skal fullføre?

Kanskje startet dere prosjektet med en klar og tydelig rollefordeling, men uten avklaring om hva hver rolle faktisk innebærer. Er du for eksempel teknisk ansvarlig må du sammen med gruppen din bli enig om helt konkrete ting som er ditt ansvar innenfor rollen din.

Alle roller er viktige, men det finnes én rolle som også har ansvar for at de andre rollene fungerer som de skal; prosjektlederen. Velg en prosjektleder som er positiv og diplomatisk, men ikke redd for å si ifra. Alle kan være ledere fordi det høres kult ut, men det er faktisk ikke alle personligheter som egner seg like bra til denne rollen. Hvis prosjektlederen er voldsomt konfliktsky eller har en tendens til å være negativt innstilt, vil dette gå ut over prosjektet. Og hvis man har endt opp i denne situasjonen, ja, da må dere ta den praten. Se neste punkt!

“Det er sikkert noen som fikser det”

I Vink-prosjektet overvurderte vi arbeidskraften vår, det fikk vi svi for. Vi var en gigantisk gruppe, derfor tenkte vi “dette ordner seg, vi er jo så mange!”. Denne mentaliteten gjør at teamet blir passivt, og forventer at andre skal fikse det. Dette er en utrolig typisk utfordring i gruppearbeid, noen er ofte flinkere til å ta initiativ enn andre, og dermed blir arbeidsfordelingen skjev. To øvelser som kan hjelpe dere mot dette er:

1. Forventningsavklaring

Dere kan bestemme selv hvilke regler dere skal ha innad i gruppen. I prosjektets første møte diskuterer dere teamets spilleregler i deres delte samarbeidsplattform. Er dere en gjeng som lider av skippertak, eller er det noen av dere som har en tendens til å overstyre idémyldringen? Her er noen forslag til hva dere kan inkludere:

Post it-lapper:

• Hvis man kommer mer enn 15 minutter sent må man bake (boller, kake, kjeks, el.) til neste møte!

• Alle må si minst én ting de har gjort på prosjektet siden sist møte, og én ting de skal gjøre til neste møte.

• Gruppejustering

Gruppejustering handler om å sørge for at dere jobber mot samme mål. Selv om målet er bestemt i fellesskap, kan gruppen ha syv forskjellige tolkninger av det samme målet. Dette fører til kaos! Felles forståelse av prosjektets mål vil gjøre arbeidskraften produktiv og forbedre kommunikasjonen. På engelsk kalles dette “team alignment”.

Disse øvelsene er ikke samarbeidsøvelser, de er ment for at dere skal dele egne perspektiver om prosjektet. Bruk to minutter på hvert punkt, og diskuter dem i fellesskap etterpå. Av erfaring er det best at alle må presentere sin lapp, og fortelle kort om hvorfor de skrev den. Prøv ut på neste møte:

Post it-lapper:

• Hva du forventer av gruppemedlemmene dine i dette prosjektet.
• Hva som er viktig for deg.
• Hva du forventer av deg selv.
• Hva du forventer av samarbeidspartnere eller faglærere.
• Hva dere prøver å oppnå med prosjektet.

Struktur

Med gode vaner og ordentlig struktur blir tiden din venn! Sett opp ukene som bolker med konkrete gjøremål og møter. Vi møtte på mange utfordringer i Vink-prosjektet vårt, og vi hadde ikke hatt tid til å takle disse om vi ikke hadde hatt en ordentlig struktur på arbeidet vårt og interne tidsfrister.

Det er ikke bare gjøremålene og tiden som trenger struktur. Materialet dere bruker må være lett å få tak i for alle på teamet. Vi anbefaler å ha et tydelig “kart” over hvor dere finner data og annet materiale. De timene vi brukte på å grave frem gamle intervjuer og notater får vi aldri tilbake! Vi brukte Miro til å kartlegge datamateriale, sette opp møtedatoer, deadlines og strukturere arbeidet for de kommende månedene. Andre gode alternativer for dette er FigJam, Notion, Monday og Trello.

Kommunikasjon og åpenhet

I et team kan man prate så mye man vil, men det betyr ikke at man forstår hverandre. Mange er så konfliktsky at man heller vil la prosjektet gå til grunne før man sier det man faktisk mener. Dette må man øve på! Husk at konstruktiv tilbakemelding er ikke personlig, og at det er viktig i formidlingen. Tre sannheter om kommunikasjon:

• For å forstå hverandre må man være ærlig selv om det kan være ukomfortabelt.
• For å løse problemer må man tørre å dele idéer uten frykt for at de er dårlige. Perfeksjonisme dreper kreativitet.
• For å vise respekt for hverandre må man lytte aktivt og spille videre på hverandres idéer, selv om man er skeptisk til den gjeldende idéen.

Vær smidige underveis

Prosjekter kan, og bør, støte på endringer i krav og omfang, spesielt etterhvert som man får mer innsikt og informasjon utover i prosjektet. Bygge, måle, lære -prinsippet handler om akkurat dette, og dere må være forberedt på å måtte endre kurs underveis.

En smidig metodikk handler om å tilpasse seg etter endringer underveis, og fokuserer på korte sykluser, eller iterasjoner. I de kommende kapitlene, den delen av boken som handler om design, tar vi for oss innsiktsarbeid, prototyping, innholdsdesign og brukeropplevelse. Dette er faser av en innovasjonsprosess som ofte gjentas flere ganger; man utforsker et problemområde, lager mulige løsninger og evaluerer hvorvidt de løser et gitt problem. Vink-prosjektet besto av tre slike iterasjoner. Det var etter brukertestene i den første iterasjonen vi skjønte at vi måtte bytte kurs; brukerne skjønte ikke hva vi ville oppnå, og det gjorde egentlig ikke vi heller. Dette var heldigvis ganske tidlig i prosjektet, og vi hadde tid til å snu. Dette var en klassisk pivot: en kurskorrigering for å undersøke et annet verdiforslag. (Les mer om pivot i kapittel 10).

For at en god og smidig prosess skal fungere, må dere ha klare roller slik at dere får til å jobbe effektivt hver for dere, slik at tiden dere bruker på å samkjøre blir effektiv. Jo bedre dere er på å fordele roller, strukturere arbeidet og kommunisere effektivt, desto fortere kan dere ha et testbart konsept som kan gi dere feedback. Og jo fortere dere har et testbart konsept som dere kan få feedback på, desto bedre blir neste iterasjon og dermed også sluttproduktet!

Google Design Sprint

En måte å utforske, designe og evaluere raskt, faktisk bare på 5 dager, er Google’s Design Sprint. Sprinten har blitt vår tried and true mal for designprosessen, som vi har gjennomført både med samarbeidspartnerne våre i Future Solutions på bachelorprosjektet, med Universitetsforlaget på masterprosjektet, og utallige ganger innad i teamet. Vi har gjort fulle 5 dagers sprinter, vi har gjort noen speedruns gjennom de viktigste fasene, eller noen ganger bare brukt én av metodene for å få i gang en idémyldringsprosess.

En Design Sprint er gøy, slitsomt, men utrolig effektivt. Før man går i gang er det, igjen, viktig med en klar rollefordeling og noen spilleregler. Bruk tiden godt, ta pauser, spis mat og drikk koffein!

(og les mer om Google Design Sprint på https://www.gv.com/sprint/)

Eksempel fra TekLab

Prosjektstyring er sentralt i alle studentprosjektene som er formidlet på TekLabs nettsted. Men det er vanskelig å finne gode eksempler fordi arbeidsfordeling og styring sjelden blir omtalt særlig nøye i rapporter.

Havkompis

Vi var medlærere på kurset MIX250 ved Universitetet i Bergen i 2023 og så på nært hold hvordan studentene jobbet.

I starten av prosjektet lagde Havkompis en forventningserklæring. De oppdaget at flere hadde en felles svakhet: å være tidsnok! For å prøve å skjerpe inn dette, så avtalte teamet at de som kom mer enn 15 minutter for sent måtte bake en kake eller boller til neste møte. I stedet for å irritere seg over at noen kom for sent, kunne man i stedet glede seg til kake på neste møte og få god stemning ut av det. I tillegg ville alle i teamet unngå å måtte bruke fritiden på å bake til møter. Dette knepet funket godt hos teamet i Havkompis, kanskje det er noe for deres prosjekt?