Vi må snakke om prosjekter

At vi som bransje endelig har tatt et oppgjør med dårlig ledelse, fokus på oppgaver over effekt og mennesker som ressurser og fulltidsekvivalenter, har vært på høy tid. Den produktorienterte modellen, eller product operating model, er en måte å tenke og gjøre IT på, som anerkjenner at det ikke lenger er en utkantsaktivitet. Det er smidig tatt til det lengste, der hele organisasjoner endres for å sentrere seg rundt kraften i autonome produktutviklingsteam og smidig tankesett.

Idéen er god, verdisettet er godt. Og som vanlig legger vi to sterke hender på rattet og drar rett fra én grøft til en annen. Derfor må vi snakke om prosjekter.

Om tykke MVPer

En av kjerneidéene smidig bygger på, er tanken om kontinuerlig og iterativ læring gjennom kontakt med den virkelige verden. Adferden til ekte brukere i møte med det du lager drar ned risikoen og gir uvurderlig innsikt om hvordan produktet ditt virker. Men hva når du ikke har noen brukere enda? Svaret i smidig produktutviklingsmetodikk er: skaff det snarest. Lag en MVP, få den i produksjon, hent inn brukere, reduser risiko og skaff innsikt.

Men hva skjer når du ikke kan, eller evner, å definere en liten MVP? Dette er ofte tilfelle i offentlig sektor og andre strengt regulatoriske bransjer, som finans, der det skal lages løsninger som må følge omfattende lovverk. Da kan for enkle MVPer rett og slett være lovstridige. Løsningen på dette blir ofte såkalte «tykke MVPer» – minimumsløsninger som inneholder mye funksjonalitet og tar lang tid å lage.

Tykke MVPer gir utviklingsløp med en del felles egenskaper:

1. Kompleks innsikt som må samles og forstås.
2. Langt løp mot første produksjonssetting, og dermed brukere i produksjon.
3. Et omfattende og langt på vei fast omfang.
4. Begrenset budsjett, gjerne kombinert med en fast tidsfrist.

Så. Behov for analyse. Ingen brukere i produksjon. Fixed scope, endelig tidsfrist. Det høres ut som et prosjekt.

Her driver vi med digital produktutvikling

Og prosjekter driver vi jo ikke med. Det er utdatert og gammeldags. Og det er det gode grunner til. Prosjekter assosieres med mye av det som har vært gjort feil i bransjen vår gjennom årene: lite respekt for menneskene som lager tjenester, liten interesse for brukerne av tjenesten og fokus på leveranse over verdi og effekt.

Men det betyr ikke at løsningen er å hive sammen flere titalls folk, kalle det produktutviklingsteam, sette inn noen fageksperter som «produktledere», klatte på noen OKRer som teller fremdrift og la det stå til. Å levere komplekse systemer er vanskeligere enn som så.

Prosjekt og smidig er ikke antiteser

Smidig er et verdisyn mer enn en metodikk. Å velge en åpenbart uegnet metodikk for konteksten, som digital produktutvikling for gjennomføring av prosjekter, er i liten grad forenlig med det smidige verdisettet.

Prosjekter har primært én iboende egenskap som bryter med sentrale antakelser i det smidige verdisettet: vi får ikke hentet kontinuerlig læring i produksjon. De beste forutsetningene for å skape verdi får du hvis du klarer å sette noe i produksjon tidlig, og iterere på det basert på læring fra ekte brukere. Hvis du uansett ikke har noe i produksjon, og løpet dit er langt, er det bedre å anerkjenne at det du driver med er et prosjekt.

Prosjekt og smidig trenger ikke være motsigelser. Et prosjektløp kan bygge på smidige verdier:

• Jobbe kontinuerlig med innsikt og læring gjennom å snakke med ekte brukere og interessenter.
• Planlegge så lite som mulig, men ikke mindre.
• Ønske endringer og nye behov velkommen, gjennom å eksplisitt tilpasse kartet til terrenget og kontinuerlig tilpasse planene til virkeligheten.
• Levere verdi så tidlig og ofte som mulig, og alltid se etter muligheten til å gjøre MVPer tynnere innenfor forsvarlige rammer.
• Fokus på effekt og gevinst, over å tilegne verdi til leveranser og funksjonalitet.
• Skape eierskap hos de som gjør jobben gjennom åpenhet, involvering og inkludering.

Og så må vi akseptere at prosjekter kommer med sine egne artefakter som har verdi i sin kontekst. Estimering, milepælsplaner, risikostyring og dokumentasjon. Spesielt spennende? Nei. Potensielt nyttig? Dessverre.

Ingen flere prosjekter!

Jeg skulle gjerne ønske at vi ikke trengte prosjektene lenger. Vi har nok en tendens til å lage prosjekter fordi vi ikke er flinke nok til å jobbe tverrfaglig med å utforske kreative måter å komme i produksjon og inkrementere på. Å definere ekte, tynne MVPer er vanskelig, og det har det alltid vært. Og det krever tett samarbeid mellom designere, jurister, fageksperter, forretningsutviklere og teknologer. Men løsningen på dette må ikke være å late som utviklingsløp på måneder og år er digital produktutvikling.

Digital produktutvikling består også av leveransefaser, delivery. Med faste frister kalles disse gjerne high-integrity commitments. Dette er et eget fag, og noe smidige team ofte sliter med. Å sette folk sammen, uten styring, ledelse og kontroll, og håpe at de skal klare å gjennomføre omfattende og kompliserte leveransefaser, er både dumt og lettere uansvarlig.

Det er som med ender. Hvis det ser ut som et prosjekt, går som et prosjekt og svømmer som et prosjekt. Da er det kanskje smart å anerkjenne at det er prosjekt.