Slutt med IT-prosjekter!

De store IT-prosjektenes tid er heldigvis forbi om man skal tro alt man leser, men hva med de små? Selv Smidige prosjekter forventes å bli ferdige på en eller annen dato i fremtiden, og når systemet er levert, skal det overleveres til linja. Er det virkelig bare størrelsen som er problemet, eller er det selve arbeidsformen som ikke fungerer?

Et prosjekt er en arbeidsform som er avgrenset fra de aktivitetene en organisasjon vanligvis gjennomfører. Det er avgrenset i tid og har et mål for hva man vil ha oppnådd når prosjektperioden er over. Typisk etableres det som en midlertidig organisasjon med personer som enten skal ut, eller tilbake til linja. Formålet er å styrke virksomhetens evne til suksess i tiden som kommer. I følge PMI: “Et prosjekt er en tidsavgrenset bestrebelse for å skape et unikt produkt eller en tjeneste” (Project Management Institute, 2004).

Det er flere årsaker til at prosjekt som arbeidsform er lite egnet. Eksempler er at det er vanskelig å realisere gevinster fortløpende og så tidlig som mulig, konflikt mellom prosjektets mål og virksomhetens mål, stor avstand mellom prosjekt- og linjeorganisasjon, en kortsiktig finansieringsmodell og utfordringer med overlevering og kunnskapsoverføring.

Alternativet er å behandle leveransene som kontinuerlige produktutviklingsløp i linja. Det vil da være enklere å realisere gevinster kontinuerlig, justere initiativene opp mot virksomhetens mål, involvere hele organisasjonen, løpende finansiering, bedre kommunikasjon og kunnskapsbygging istedenfor kunnskapsoverlevering.

Men prosjektene er jo Smidig!

Mange IT-prosjekter benytter en Smidig gjennomføringsmodell. Dette gjør de for å få bedre forutsigbarhet i prosjektene sine. Det er vel og bra, men ikke tilstrekkelig. Problemet sitter ikke i Smidig som sådan, men utenfor. Om Smidig lykkes i å unnfange og utvikle programvare raskt og taktfast så må alt utenfor være i stand til å ta imot det som produseres i samme takt. Hovedutfordringene med det er at mottaksapparatet sjeldent sitter i prosjektene selv og at Smidige prosjekter sjeldent tar inn over seg at programvareutvikling strekker seg langt utover å levere “programvare som fungerer”. Hvordan programvaren oppfører seg i produksjon etter overlevering er dessverre alt for sjeldent Smidig-teamets ansvar.

“You Build It, You Run It”

Prosjektmedlemmer er avgrenset fra linjeorganisasjonen, og deres involvering med produktene de lager er tidsbegrenset. De slipper å leve med de langsiktige resultatene av deres egne arkitektur- og designbeslutninger. Dette medfører som regel dårligere utviklingspraksiser i prosjektene og gradvis forverret kvalitet. Dette forsterkes ytterligere av at man som regel har dårlig tid i prosjekter. Prosjektmedlemmene er som regel skjermet fra analyse og gjenoppretting ved produksjonsproblemer. De tvinges ikke til å legge inn nødvendig overvåkning og nødvendig logging for analyse av rot-årsaker. Teamet gjør ofte et begrenset antall produksjonssettinger og har derfor få insentiver til å investere i automatisering og produksjonslike miljøer. Linjeorganisasjonen er som regel underbemannet og har knappe ressurser og liten evne til å håndtere overleveringer fra prosjekter. De må dessuten administrere, overvåke og supportere eksisterende IT-systemer.

I Amazon.com, hvor de fokuserer på produkter fremfor prosjekter, er det et viktig prinsipp at de som lager systemene også skal drifte systemene og leve med dem i lang tid. Helt til de dør. “You Build It, You Run It” som Werner Vogels (CTO i Amazon) sier. I Amazon.com har de ikke egne driftsteam. Teamene håndterer selv både drift og utvikling. Det er dette som kalles DevOps.

Da Kent Beck besøkte DevOps Norway Meetup for et par år siden ble han bedt om å definere hva han legger i begrepet DevOps. Hans svar var: “Developers carry beepers”. Når utviklingsteamet får ansvar for å ha beredskap selv, er insentivene på plass for å lage virkelig driftbare systemer. Forvaltning og drift flyttes til starten av utviklingsløpet. Teamet organiseres som en forvaltningsorganisasjon fra dag én.

Realiser forretningsbehov, ikke lag komponenter

IT-prosjekter har som regel en målsetning om å lage en eller flere nye komponenter eller implementere den nye funksjonaliteten i eksisterende komponenter ved å utvide dem. Teamene får ofte ansvar for en komponent eller et sett med komponenter. Årsaken til at det gjøres på denne måten er som regel et iboende ønske om at teamene skal få jobbe uforstyrret uten involvering og støy fra resten av virksomheten eller andre team.

Med denne oppsplittingen har man allerede lagt unødvendige begrensninger. Har team ansvar for bestemte komponenter implementeres ny funksjonalitet som regel i disse komponentene som de kjenner godt. At funksjonen bedre kan implementeres i en annen komponent eller på tvers av flere komponenter forsvinner fort med et slikt navlebeskuende fokus. Et team har til og med kanskje ikke lov til å røre andre team sine komponenter, eller det kan være unødvendig tungvint å få andre team til å implementere påkrevd funksjonalitet.

Om man isteden organiserer teamene rundt konkrete forretningsbehov, slik det gjøres i for eksempel Spotify, vil systemarkitekturen speile forretningen bedre. I henhold til Conway’s lov fra 1968 så speiler strukturen på IT-systemene organisasjonens struktur. For å oppnå systemer som speiler forretningsstrukturen må man derfor la team organisere seg rundt forretningsbehov og ikke komponenter.

Setter man sammen langlevde team rundt behov som understøtter forretningen, så forsterkes forståelsen for virksomhetens visjon. Når teamene vet hva man skal oppnå blir det lettere å ta de rette valgene. Man vet hvor man vil med produktene som lages, og hvilken verdi man ønsker å oppnå. Teamenes eierskap, ansvarsfølelse og stolthet styrkes.

Kontinuerlige Leveranser og DevOps

Autonome team som har ansvaret for hele livssyklusen til programvare, og som samtidig forstår og deler forretningens visjon og målsetninger, lager robuste systemer som tåler rask flyt til produksjon. De sikrer at det ikke går på bekostning av kvalitet, tilgjengelighet, stabilitet, sikkerhet og så videre. I The State of DevOps Report for 2015 avdekkes det blant annet at virksomheter som jobber på denne måten har 30 ganger hyppigere produksjonssettinger, 200 ganger kortere ledetid, 60 ganger færre feil og 168 ganger raskere gjenopprettingstid ved problemer, enn sammenlignbare virksomheter.

Denne måten å jobbe på er ikke som Smidig. Smidig impliserer ikke kontinuerlig. I Smidig jobber man som regel med batcher og iterasjoner, med mer planlegging, og med testing og akseptanse med jevne mellomrom. Kontinuerlige Leveranser innebærer at programvaren kan produksjonsettes til enhver tid. Siste versjon av kildekoden kan slippes i produksjon når som helst uten behov for forberedelser eller tilpasninger. I Smidig fokuseres det ikke nok på driftsplattformen og ansvarliggjøring av utviklingsteamet for at programvaren som lages skal fungere i lang tid etter at det er i produksjon.

DevOps er en forutsetning for å kunne drive med Kontinuerlige Leveranser. De tradisjonelle overleveringene fra utvikling til drift forhindrer kontinuerlige leveranser, så teamene må drifte programvaren de lager selv. Det fordrer kompetanse om drift og utvikling. Tradisjonelt sett er drift og utvikling to separate fagfelt som krever ulike typer IT-kompetanse. I dag har imidlertid fagfeltene smeltet sammen og det ser ganske annerledes ut. Det holder ikke lenger at den eksisterende driftsavdelingen samarbeider tett med utviklingsavdelingen (selv om det hjelper). Isteden overtar teknologer som behersker begge fagfeltene og som kan både utvikle og drifte løsninger. Infrastruktur skrives og dokumenteres som kode (software defined everything), konseptet server har endret seg med immutable infrastruktur og kontainere, testing og produksjonssettinger er helautomatisert, overvåkning er mye mer omfattende. Ikke minst skydrift har revolusjonert måten programvare driftes på.

Fra CapEx til OpEx

CapEx (Capital expenditures) er investeringer man gjør på forhånd for å skape fremtidige gevinster. OpEx (Operational expenditure) er investeringer som gjøres underveis mens forretningen forløper som normalt, “business as usual”. Skydrift er et eksempel på en pay-as-you-go finansieringsmodell hvor elastisiteten og fleksibiliteten gjør at du kan skalere opp eller ned underveis istedenfor å investere i egen infrastruktur og overkapasitet før du trenger den eller vet hva du har behov for. Jeg snakker her selvsagt om offentlig sky og ikke privat.

IT-prosjekter har budsjetter som er satt av på forhånd. De har risiko. Det er bra å investere i IT, men disse investeringene behøver ikke nødvendigvis å gjøres på forhånd. Når utvikling av funksjoner følger resten av virksomheten tett, vil det være mer fornuftig å smøre kostnadene tynnere utover i organisasjonen. Det betyr ikke at man ikke kan satse stort på et område som koster mye, og som gir stor gevinst tilbake. Forskjellen er at risiko reduseres dramatisk om man tar en gradvis tilnærming til en dyr, men potensielt innbringende satsning. Gjennom å finansiere eksperimenter og gi de mest lovende initiativene mer penger når de trenger det, og de mindre lovende mindre eller ingenting, sikrer man en utvikling som er tettere knyttet opp mot forretningens mål enn gjetning på et alt for tidlig tidspunkt. Hensikten med å eksperimentere mer er å unngå å bli fanget i et blindspor. Om en satsning viser seg å bli innbringende kan man finansiere ytterligere for å maksimere uttak av gevinster.

Denne tilnærmingen er ikke nødvendigvis så enkel — det kan være vanskelig å balansere prioriteringer og budsjettering. Det krever at IT-utvikling blir en integrert del av forretningsutvikling og at resultater og hypoteser verifiseres kontinuerlig. Her gjelder det å innse at alle virksomheter i dag er IT-virksomheter og at det er en dårlig idé å ha et skille mellom IT og forretning om man skal lykkes.

The End

Om du er enig i at prosjekter er en dårlig gjennomføringsmodell vil jeg anbefale å ikke gjennomføre de foreslåtte endringene som et prosjekt. Begynn å eksperimentere med nye idéer i linjeorganisasjonen. Sett sammen autonome team som besitter alt som skal til for å gjennomføre eksperimentene. Sørg for at eksperimentene er målbare. Det er en selvfølge at forretningsfolkene deltar i tett samarbeid med teamet. Start billig! Bruk Sky! Sørg for at teknologene har full tilgang til produksjonsmiljøene og at de har ansvaret helt fra unnfangelsen av programvaren og til den avgår med døden. Teamet må ha beredskap! Lever programvare kontinuerlig til produksjon fra dag én. Det er den beste måten å få feedback på, og det finnes ikke noe bedre testmiljø enn produksjon. Organiser teamene rundt forretningsbehov. Ikke lag team med ansvar for komponenter. Just do it! Slutt med IT-prosjekter!

Diskusjon

Jeg har limt inn diskusjonen fra der posten ble publisert første gang.

• Sverre Stornes
• Kul artikkel. Hvordan løser vi kontraktsformen, var min første tanke.
• Stein Inge Morisbak > Sverre Stornes
• Jeg er ingen kontrakt-ekspert, men det bør da være mulig å utforme kontrakter som langsiktige samarbeidsavtaler hvor leverandørens folk blir en del av linja. Ett av problemene med prosjekter er at de ofte ikke jobber tett nok med linja og at overleveringer dermed blir vanskeligere. Så lenge både leverandørene og virksomhetene er involvert i forretningsutviklingen forsvinner mange av disse utfordringene.
• Sverre Stornes > Stein Inge Morisbak
• Kan fungere, men tenker at opex-en kan bli utfordrende for kunden på lang sikt. Varianten er at man “leier” inn “sine” devopser på deltid. Det er mulig at det hadde vært lettere å få en win-win-økonomi dersom et team supporterte flere kunder samtidig. Dog, dermed er det også en viss risiko for at man ikke kjenner løsningen godt nok.
• Stein Inge Morisbak > Sverre Stornes
• Jeg synes du svarte godt på ditt eget spørsmål. Det fungerer dårligere om det blir for stor avstand mellom de som skal drifte systemene og de som lager dem. Sannsynligheten for misforståelser og dårlig kommunikasjon øker, og de måles på forskjellige ting. Utvikling på endring og drift på stabilitet. Disse målene står etter mitt syn i sterk kontrast til hverandre.
• Det er også viktig å påpeke at jeg synes det er en dårlig idé å leie inn “devopser” på deltid eller å lage egne devops-team. Utviklingsteamene må selv besitte all kompetanse som skal til for å utvikle, drifte og forvalte det de lager. Man må finne den rette sammensetningen og la teamene få det fulle ansvaret.
• Trond Arve Wasskog > Sverre Stornes
• Kontraktsformen blir vel løpende timer. Målpris eller fastpris er vanskelig å se for seg når man ikke kjører prosjekter.
• Sverre Stornes > Trond Arve Wasskog
• Løpende timer for vakttelefon, håndtering av hendelser og andre guffne greier? Jeg er “all in”, men tenker at kunden muligens er noe risikoavers med tanke på support og overvåkning…
• Trond Arve Wasskog > Sverre Stornes
• Kompensasjon for beredskap og utrykning er ganske enkelt å få på plass for team som eier produktene sine. Og når teamet selv må håndtere vakt og beredskap er vår erfaring at robustheten forbedres vesentlig, og at man sjelden har behov for å rykke ut natt til søndag eller andre ugudelige tidspunkter.
• Sverre Stornes > Trond Arve Wasskog • for 2 år siden
• Enig, men hvordan gi trygghet til kunden. Jeg tenker det er en viss omstilling fra, hmm, legacykontrakter og over til verdiskapningskontrakter
• Ola Nordigarden
• Er veldig enig i at tradisjonell wterfall og lange prosjekter ikke er forenlig med effektiv utvikling. Det som er veldig frustrerende er at kvalitet og sikkerhet ser ut til å ha gått i glemmeboken når det gjelder alternativene — det blir dyrt i lengden for kunder som bruker konsulenter som kun leverer halvfabrikata
• Trond Arve Wasskog > Ola Nordigarden
• Forstår jeg det riktig at kvaliet og sikkerhet går i glemmeboken om du håndterer produktene i linja framfor prosjekt? Kan du eventuelt utdype hvorfor?
• Ola Nordigarden > Trond Arve Wasskog
• Stikkord: MOD 1 hos NAV…
• Torgeir Helgevold
• Jeg tror det en et godt poeng at selvstyrende team kan ta seg av både utvikling og selve driftingen. Jeg har erfaringer fra et par prosjekter der det var modellen. Cloud hosting har vel på en måte senket terskelen for at man nettopp kan ta seg av en del av driftingen av servere etc. Dette sammen med god test coverage og enkel deployment fungerer veldig godt for hyppige releaser.
• Et annet moment som glemmes litt i Agile/smidig er kundesupport som ofte lider under manglende eller gammel dokumentasjon. Jeg er selv fan av agile, men mener “support staff” kanskje har et bra argument når de sier at deres jobb er vanskeligere i Agile prosjekter — nettopp pga mangelfull dokumentasjon. Tenker på support der kundebehandlere er avhengig av en slags manual for å kunne forklare brukere hvordan systemet funger etc. Sier ikke dette er i direkte konflikt med smidig, men tror de fleste tar snarveier her.
• Poenget ditt med å ikke lage komponenter er noe å tenke på også. Det er for tiden mye snakk om Microservices, men det er vel egentlig en motsetning til komponent argumentet ditt. Jeg er litt usikker på hva som er det beste akurat her. Ser litt fordeler med begge varianter.
• Stein Inge Morisbak > Torgeir Helgevold
• Bra at du tar opp dette Torgeir. Det er viktig å ha support som er i stand til å gjøre jobben sin effektivt og med høy kvalitet. Verdien det gir bør virksomheten ha et forhold til og det bør måles hvor effektivt og godt det fungerer. Om hypotesen er at dokumentasjonen er for dårlig synes jeg man skal ta to steg tilbake og vurdere om det kan være flere årsaker og løsninger enn å stille krav til omfattende dokumentering (som ofte kan bli utdatert før det er ferdig skrevet). Kan det være at produktene er for lite selvforklarende? Bør det lages dokumentasjon som lar brukerene finne ut av de fleste problemer selv? Bør det lages IT-verktøy for support istedenfor nedskrevne forklaringer? Om det likevel viser seg at det er dokumentasjon som er mangelfull. Ja da må man lage dokumentasjon.
• Hos kunden min har vi gjort mye for å forbedre support. Vi har målt mye, laget hypoteser og vurdert alternativer. Løsningen vi fant som ga størst effekt var å legge opp til mest mulig selvbetjening og enkle brukergrensesnitt for de vanligste oppgavene support utfører, som for eksempel å søke og gjøre endringer i kundedata, og innsyn i hendelser i systemet. Det vil være ulike løsninger for ulike problemer. Måling av effekten de ulike tiltakene har er superviktig.
• Mikrotjenester virker etter mitt syn fornuftig i denne sammenhengen. En av fordelene er nettopp at de lages for å speile forretningen og organisasjonen bedre. De gjør det også enklere å forvalte, bytte ut, skalere og gjøre endringer i på grunn av uavhengigheten mellom delene. Med komponenter mener jeg systemer hvor mye funksjonalitet er klumpet sammen og hvor letteste vei til mål er å utvide de allerede for store komponentene med funksjoner som har for sterke bindinger til hverandre.
• Stefan Magnus Landrø > Stein Inge Morisbak
• Jeg må si meg veldig enig med det Stein Inge Morisbak skriver ang dokumentasjon. Selv mener jeg brukermanualenes tid er over. Når iOS kommer i ny versjon, er jeg riktig så glad for at jeg slipper å lese en lang manual. Det samme gjelder når google, facebook eller andre ruller ut ny funksjonalitet. Slik jeg ser det, er behov for dokumentasjon, et meget tydelig varsko om at systemet er vanskelig å bruke. Nå er det dessverre ikke slik at man alltid klarer å lage super-brukervennlige funksjoner fra dag én, og da tenker jeg at henvendelser til en support-organisasjon, er verdifull input for å forbedre produktet.
• Arne Berner
• Fin artikkel, enig i mye, men sliter med å realisere dette i praksis. Skal forsøke altså…
• Jeg tror kanskje bildet er noe mer nyansert.
  Ikke alt er IT-utviklingsprosjekter, eller ihvertfall ikke i starten av livssyklusen.
  La oss ta eksemplene med et sak/arkiv-system eller et system for timeføring.
  Dette er systemer man i stor grad ikke vil utvikle selv men vil anskaffe som et ferdig produkt, og så tilpasse.
  Hvordan skal en virksomhet organisere en slik aktivitet uten at det blir et IT-prosjekt?
• noen tanker?
• Stein Inge Morisbak > Arne Berner
• Det er ikke nødvendigvis noe galt i å kjøpe hyllevare, men tilpasninger av slike produkter viser seg dessverre ofte å være problematisk. Oppgraderinger kan for eksempel være vanskelig med mye skreddersøm. Løsninger som er “en løsning på alle dine problemer” bør man etter mitt syn holde seg unna. Enkle løsninger som løser ett problem på en god måte er bedre. At de er enkle å integrere mot er også viktig. Da kan man heller legge skreddersømmen i andre tilgrensende komponenter. Velger man en slik tilnærming blir det lettere å gjøre ting gradvis og å unngå større eller mindre IT-prosjekter i forbindelse med innføring. Altså: Ikke forsøk å løse alle problemer med ett stort system og et IT-prosjekt.
• Arne Berner > Stein Inge Morisbak
• Enig.
  Men like fullt tror jeg at det for mange vil være riktig å organisere anskaffelsen av et enkelt standard system som et lite isolert IT-prosjekt. Selvsagt med personer fra linja.
  Mange som kjøper slike systemer har utfordringer med å utforme krav slik at man får et slikt system som det du beskriver, det kommer både av at kjøper ikke vet bedre og av at leverandør ikke alltid tilbyr et slikt produkt.
• Stein Inge Morisbak > Arne Berner
• Hm. Det er ikke så lett å svare på det uten å kjenne til spesifikke eksempler. Det avhenger mye av størrelsen på anskaffelsen og hvor mange behov/krav som skal tilfredsstilles.
• Er det en stor anskaffelse vil det kanskje være en løsning å involvere leverandøren i linjearbeidet og sørge for en gradvis innføring og kunnskapsbygging i tett samarbeid. Da unngår man ihvertfall et isolert prosjekt som overleveres “big bang” etter at det er “ferdig”.
• Er det flere relativt isolerte krav og behov er min erfaring at det kan være lurt å handle flere steder og ikke alt på en gang. Det kan være krevende for kjøper, men det vil sannsynligvis kreve enda mer å leve med et gigantsystem som “løser alt”.
• Trond Arve Wasskog > Arne Berner
• Hvem skal eie sak-/arkivsystemet etter anskaffelsen? De som skal tilpasse, forvalte og drifte systemet i linja bør også stå for anskaffelsen. Kan kreve at man leier inn kompetanse og kapasitet i innføringsfasen, men nøkkelen er fortsatt å unngå en overlevering til linja etter anskaffelsen.
• Arne Berner > Trond Arve Wasskog
• Men jeg som skal anskaffe og bruke dette systemet vet jo ikke noe om drift og forvaltning. Det er jo tjenester jeg kjøper det også. Kanskje av samme leverandør, kanskje av en annen.
• jeg vil gjerne ha en situasjon slik som beskrives her men jeg vet ikke helt hvordan vi får det til. Kanskje artikkelen her er ment for teknologi bedrifter, for leverandører, for bedrifter som driver produktutvikling. Og at det ikke gjelder for små og mellomstore offentlige virksomheter.
• Trond Arve Wasskog > Arne Berner
• Men tenker du da at et prosjekt håndterer denne anskaffelsen? Kanskje vurdere om en SaaS-applikasjon løser behovet, for å unngå drift/forvaltning/tilpasning.
• Martin Koksrud Bekkelund
• Du har forskningen med deg, Stein Inge: Nyere norsk (!) forskning viser at kombinasjonen av smidig metodikk
  og kontinuerlige leveranser gir den beste kvaliteten på sluttproduktet.
  Samtidig viser den samme forskningen, overraskende nok, at smidige
  metoder alene — det vil si uten kontinuerlige leveranser — at kvaliteten
  er dårligere enn tradisjonelle metoder som f.eks. vannfall. Enjoy: https://www.simula.no/publi...
• Stein Inge Morisbak > Martin Koksrud Bekkelund
• Ikke uventet, og veldig hyggelig at forskning synliggjør dette. Det er beklagelig at innføring av Smidig mange steder ikke har medført kontinuerlig forbedring. Jeg kan forstå at det kan være mer til skade enn hjelp. Å splitte opp organisasjonen i mange små team uten tett samarbeid med forretning, med strikse rammer for arkitektur og teknologivalg, relativt statiske produktkøer, seremonier som ingen skjønner vitsen med, demoer av programvare som ikke skal i produksjon før om en måned eller lenger, osv. forstår jeg er vanskelig å gjennomføre på en god måte. Mange Scrummer små gjør et stort vannfall om man ikke forstår mulighetene og implikasjonene ved å innføre Smidig. Taktfast og rask flyt av verdifull programvare til produksjon er en forutsetning for å lykkes med Smidig.
• Trond Arve Wasskog > Martin Koksrud Bekkelund
• Spørsmålet er om man jobber smidig om man ikke leverer kontinuerlig? Det første prinsippet i det smidige manifestet er: “Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranserav programvare som har verdi”. http://agilemanifesto.org/i...
• Det bør ikke overraske noen at smidige metoder i fåreklær gir begrenset gevinst.