Behandle  IT-­‐utvikling    som    

Business  as  Usual  

Geir  Amsjø  Axio  Consul<ng  

Prosjektet  -­‐  en  naturlig  arbeidsform  

...  særlig  når  leveransen  er  veldefinert  

Planlegg  -­‐  gjennomfør  -­‐  vedlikehold  

Oppstarts-­‐  fase   Prosjek5ase   Vedlikeholdsfase  

Her  gir  oppdragsgiver  (”linja”)  ansvaret  ?l  en  midler?dig  organisasjon  i  en  forholdsvis  kort  fase  

Her  overtar  linja  produktet  og  tar  ansvaret  for  vedlikehold  i  resten  av  dets  leve?d  

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  forskriJer  

Stor  grad  av  dynamikk  

Es<matene  er  svært  unøyak<ge  

Teambygging  tar  <d  

Kostnadene  størst  i  vedlikehold  

Oppstarts-­‐  fase   Prosjek5ase   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  

Produk'v  'd   Produk'v  'd   Produk'v  'd  

Én  kø,  faste  team  

Sprints  

Scop

e  

PM  1  

PM  2  

PM  3  

Interessenter  

Produkteier  

Én  produ

ktkø  

                                                     En  permanent,  ansvarlig  organisasjon  

Problemer  i  IT-­‐systemer  

Opplevd  kvalitet    

Feil  

Evtentuelle  mangler  

Struktur  

Design  Arkitektur  

Le6a8elighet  

Oppdages  med    en  gang  

Oppdages    ganske  raskt  

Oppdages  lenge  eWer    prosjektets    sluW  

Vedlikeholdbarhet

Ulempene  med  prosjekt  innen  IT-­‐utvikling?  

Dyrt  Risikabelt  

Ofrer  kvalitet  Rigid  

Dyrt  Oppstarts-­‐  fase   Prosjek5ase  

Konsept-­‐  utredning  

For-­‐prosjekt  

Krav-­‐spesifisering  

Grovdesign  

Planlegging   Anbuds-­‐innbydelse  

Kontrakts-­‐inngåelse  

Prosjekt-­‐oppstart  

Løsnings-­‐beskrivelse   Utvikling  

Systemtest  Integrasjon  

Akseptansetest  

Overlevering  

Avslutning  

Detalj-­‐planlegging  

2  år  1  år   3  år  

Produk'v  'd  

Dyrt  (II)  KompleWhetssyken  

Vi  skal  vite  kostnaden  på  forhånd,  ergo  må  vi  ”tenke  på  alt”  

Henrik Kniberg

Maximize Value, not Output

Dyrt  (III)  Byråkra<sk  

Prosjektet  forplikter  seg  typisk  ?l  en  kompleU  spesifikasjon,  ergo  er  ”alt  i  arbeid”  fra  start  ?l  mål.    

Dedikerte  roller  for  koordinering,  styring,  rapportering.    

Dyrt  (IV)  Store  ventekostnader  

Når  en  gevinst  er  iden?fisert  begynner  det  å  løpe  ventekostnader.    

Dyrt  (V)  Kostbare  endringer  

Endringer  i  forhold  ?l  avtalt  omfang  innebære  øket  ?dsbruk  og  kostnad.  

Endringsbehandling  må  være  en  formell  prosess,  med  en  kostnad.  

Risikabelt  

RISIKO Tid  

Kost  

Oppstarts-­‐  fase   Prosjek5ase  

Her  får  vi  validert  alle  antagelsene  

Ofrer  kvalitet  

Prosjektets    variable  

Håndverket   Tid  

Kostnader  Omfang  C

oC

Endringskostnad  ideell  

Endringskostnad  reell   Teknisk  

gjeld  

Ingen  vil  oppdage  at  vi  ofret  det  gode    håndverket  før  lenge  eUer  sluUerminen.  

Ofrer  kvalitet  (II)  

Det  gode  håndverket  er  ikke  giU  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  rammebe?ngelser,  omgivelser,  prioriteringer  og  behov  endrer  seg  mens  prosjektet  løper.  

Endringer  har  en  kostnad  

FOKUS  

Prosjekter  har  en  tendens  ?l  å  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  

UtnyU  fordelene  av  å  etablere  permanente    systemutviklingsteam    

som  realiserer  gevinster  på  løpende  bånd.    

Ta  virkeligheten  på  alvor!