IT-utvikling som Business as Usual

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!