Prosjektet egner seg for ekstraordinære leveranser, men for svært mange organisasjoner er IT-utvikling noe som skjer nærmest kontinuerlig. Da er prosjektmekanismen ikke bare unødvendig med også uhensiktsmessig.

1. Behandle IT-utvikling
som
Business as Usual
Geir Amsjø
Axio Consulting

2. Prosjektet - en naturlig arbeidsform

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

4. 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

5. Hva er det som er så
spesielt med IT-
utvikling?

7. Systemene blir aldri ferdige

8. Stor kompleksitet

9. Ingen fasit-svar,
”uendelig antall” løsninger

10. Store deler av leveransen er
usynlig og/eller uforståelig

11. Ingen standarder eller forskrifter

12. Stor grad av dynamikk

13. 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

14. Har denne verdi?

15. IT-utvikling ”i linja”
Permanent IT-utvikling

16. Agile processes promote
sustainable development.
The sponsors, developers,
and users should be able
to maintain a constant
pace indefinitely.

17. IT-utvikling ”i linja”
Permanent IT-utvikling
Produktiv tid Produktiv tid Produktiv tid

18. Én kø, faste team
Sprints
Scope
PM 1
PM 2
PM 3
Interessenter
Produkteier
Énproduktkø
En permanent, ansvarlig organisasjon

19. Ulempene med prosjekt
innen IT-utvikling?
Dyrt
Risikabelt
Ofrer kvalitet
Rigid

20. Dyrt
Oppstarts-
fase Prosjektfase
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 år1 år 3 år
Produktiv tid

21. Dyrt (II)
Kompletthetssyken
Vi skal vite kostnaden på forhånd, ergo må vi ”tenke på alt”

22. 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.

23. Dyrt (IV)
Store ventekostnader
Når en gevinst er identifisert begynner det å løpe ventekostnader.

24. 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.

25. Risikabelt
Tid
Kost
Oppstarts-
fase Prosjektfase
Her får vi validert alle antagelsene

26. Ofrer kvalitet
Prosjektets
variable
Håndverket Tid
KostnaderOmfang
CoC
Teknisk
gjeld
Ingen vil oppdage at vi ofret det gode
håndverket før lenge etter slutterminen.

27. 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.

28. Rigid
Prosjektet vil forsøke å unngå endringer, selv om
rammebetingelser, omgivelser, prioriteringer og behov endrer seg
mens prosjektet løper.
Endringer har en kostnad

29. FOKUS
Prosjekter har en tendens til å trekke fokus mot seg.
Vil prosjektet lykkes?
Trekk heller fokus over mot produktet.
Vil produktet lykkes?

30. 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!