it-utvikling som business as usual
TRANSCRIPT
Behandle IT-utvikling som
Business as Usual
Geir AmsjøAxio Consulting
Prosjektet - en naturlig arbeidsform
... særlig når leveransen er veldefinert
Planlegg - gjennomfør - vedlikehold
Oppstarts- fase Prosjektfase Vedlikeholdsfase
Her gir oppdragsgiver (”linja”) ansvaret til en midlertidig organisasjon i en forholdsvis kort fase
Her overtar linja produktet og tar ansvaret for vedlikehold i resten av dets levetid
Hva er det som er så spesielt med IT-
utvikling?
Systemene blir aldri ferdige
Stor kompleksitet
Ingen fasit-svar, ”uendelig antall” løsninger
Store deler av leveransen er usynlig og/eller uforståelig
Ingen standarder eller forskrifter
Stor grad av dynamikk
Kostnadene størst i vedlikehold
Oppstarts- fase Prosjektfase Vedlikeholdsfase
Produktets totale livssykluskostnader avgjøres av vedlikeholdsvennligheten – som avgjøres av den håndtverksmessige standarden i utviklingsprosjektet
Har denne verdi?
Ja, og den kan gi oss feedback
IT-utvikling ”i linja”
Permanent IT-utvikling
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
IT-utvikling ”i linja”
Permanent IT-utvikling
Produktiv tid Produktiv tid Produktiv tid
Én kø, faste team
Sprints
Scop
e
PM 1
PM 2
PM 3
Interessenter
ProdukteierÉn
pro
dukt
kø
En permanent, ansvarlig organisasjon
Ulempene med prosjekt innen IT-utvikling?
DyrtRisikabelt
Ofrer kvalitetRigid
DyrtOppstarts- fase Prosjektfase
Konsept-utredning
For-prosjekt
Krav-spesifisering
Grovdesign
Planlegging Anbuds-innbydelse
Kontrakts-inngåelse
Prosjekt-oppstart
Løsnings-beskrivelse Utvikling
SystemtestIntegrasjon
Akseptansetest
Overlevering
Avslutning
Detalj-planlegging
2 år1 år 3 år
Produktiv tid
Dyrt (II)Kompletthetssyken
Vi skal vite kostnaden på forhånd, ergo må vi ”tenke på alt”
Dyrt (III)Byråkratisk
Prosjektet forplikter seg typisk til en komplett spesifikasjon, ergo er ”alt i arbeid” fra start til mål.
Dedikerte roller for koordinering, styring, rapportering.
Dyrt (IV)Store ventekostnader
Når en gevinst er identifisert begynner det å løpe ventekostnader.
Dyrt (V)Kostbare endringer
Endringer i forhold til avtalt omfang innebære øket tidsbruk og kostnad.
Endringsbehandling må være en formell prosess, med en kostnad.
Risikabelt
RISIKOTid
Kost
Oppstarts- fase Prosjektfase
Her får vi validert alle antagelsene
Ofrer kvalitet
Prosjektets variable
Håndverket Tid
KostnaderOmfangCoC
Endringskostnad ideell
Endringskostnad reell Teknisk gjeld
Ingen vil oppdage at vi ofret det gode håndverket før lenge etter slutterminen.
Ofrer kvalitet (II)
Det gode håndverket er ikke gitt og krever utprøving og feedback.
Ingen læring underveis
Hvorfor skal prosjektet drive med prosessforbedring?
Solid kvalitet avhenger mest av eierskap.
Rigid
Prosjektet vil forsøke å unngå endringer, selv om rammebetingelser, omgivelser, prioriteringer og behov endrer seg mens prosjektet løper.
Endringer har en kostnad
FOKUS
Prosjekter har en tendens til å trekke fokus mot seg.Vil prosjektet lykkes?
Trekk heller fokus over mot produktet.Vil produktet lykkes?
Oppsummert
Ikke behandle IT-systemer som om de var fysiske produkter
Utnytt fordelene av å etablere permanente systemutviklingsteam
som realiserer gevinster på løpende bånd.
Ta virkeligheten på alvor!