Keiserens gamle, loslitte klær

På tide å kle av prosjektveiviseren!

Følgende artikkel ble i dag 21.02.14 publisert som med tittelen Utdatert Utvikling i Dagens Næringsliv. Signert Benjamin Sommer og Geir Amsjø, Axio Consulting.

———————

Digitaliseringen av Norsk offentlig forvaltning skal få et løft gjennom IT-prosjekter etter en utdatert, standardisert mal. Er Killengreen og Chaffey klar over hva de gjør?

Det er rart hvordan avdanket teknologi og forkastet tankegods kan få noen ekstra leveår i det offentliges regi. Disketten (og maskiner som kan lese disketter) har fremdeles et marked i norsk helsevesen. Bra for de som lever av sånt, men er selvsagt svært ineffektivt.

 

prosjektveiviser

På samme måten er Prosjektveiviseren.no som Direktoratet for forvaltning og IKT (Difi) lanserte ny versjon av rett før jul basert på forkastet tankegods når det gjelder programvareutvikling. Veiviseren institusjonaliserer ”vannfallsmodellen” der prosjekter går igjennom 5 ulike faser, med beslutningspunkter mellom hver fase. Gevinster tas ut når hele prosjektet omsider er ferdig. Dette kan fungere godt for en del typer prosjekter, men er særdeles lite egnet for kunnskapsintensivt, dynamisk og innovativt arbeid som programvareutvikling vitterlig er. Ingen av de store, men fremdeles unge programvarebaserte lokomotivene i IT-bransjen (som Google, Amazon, Facebook, eBay, Yahoo, Salseforce.com, Spotify, FINN.no, for å nevne noen få) benytter denne modellen. Veldefinerte, standardiserte fasemodeller er 90-tallets forsøk på å øke suksessraten til IT-prosjektene. Vi vet i dag hvordan det gikk.

Prosjektveiviseren ble 18 desember 2013 presentert i et 4 timer langt seminar publisert her: http://www.prosjektveiviseren.no/2013/12/digitalisering-gir-gevinster. Ingelin Killengreen innledet og snakket varmt om å ”forenkle, fornye, forbedre”. Paul Chaffey overtok så og holdt et godt innlegg om viktigheten av å realisere gevinstene. Han ville ha fokus på innovasjon, gjennomføringsevne og endringsledelse. Og han avsluttet med å si at ”Difi kommer til å bli departementets viktigste verktøy!”

Den dårlige nyheten er at all erfaring viser at denne vannfallsmodellen fører til sløsing med kalendertid, byråkrati, høy risiko, dårlig kvalitet og er lite egnet til innovasjon. Den er på mange måter naturstridig når vi tenker på hva programvareutvikling egentlig dreier seg om. Vannfallsmodellen ble adoptert og institusjonalisert av US Department of Defence på 1970-tallet og har siden det vært den rådende framgangsmåten. Det er i den forbindelse svært interessant å merke seg at DoD nå synes å ha forkastet modellen og er i full gang med å institusjonalisere ”Agile”! (http://scrum.jeffsutherland.com/2012/04/dod-goes-agile.html)

I 2001 kom startskuddet for det som skulle revolusjonere programvarebransjen; ”The Agile Manifesto”. Dette manifestet definerte helt nye suksessfaktorer og verdier som er tilpasset programvareutvikling. Manifestet sier slike ting som ”Individuals and Interactions over Processes and Tools”. Dette innebærer mao at om de individene som gjør jobben er høyt motiverte, kompetente og samarbeider godt, vil det bety mer for suksess enn verdens beste, veldefinerte prosessbeskrivelser, prosedyrer og sjekklister.

Agile baserer seg på mye av den samme tankegangen som vi finner i Lean. Vi dyrker for eksempel ”pull-prinsippet” der markedet til enhver tid bestemmer hva vi fokuserer på, og at vi tilpasser kapasiteten til etterspørselen. Vi realiserer gevinster tidlig og løpende i tett dialog med interessentene. Det er til syvende og sist vår evne til å lære underveis som vil bestemme hvor godt resultatet blir. På denne måten blir også robustheten til selve produktet langt bedre ivaretatt, og risikoen lavere. Agile representerer mao et annet paradigme, optimalisert for dynamikk, hurtighet , kvalitet og innovasjon. Prosjektstyring er ikke lenger viktig.

”IT-skandalene” er mange i dette landet, og vannfallsmodellen må bære mye av ansvaret. Vi skal ikke ramse alle disse her, men nøye oss med å nevne ett eksempel referert i DN (http://www.dn.no/forsiden/politikkSamfunn/article2546457.ece) som forteller at Estland har kommet i mål med et elektronisk pasientregistersystem for 82 mill kroner. Norge har hittil brukt over en milliard, og har planer om å bruke nye hundretalls millioner.

Det er naturlig at forvaltningen og IT-bransjen har store forventninger til en blå regjering på områder som fornying, innovasjon og effektivisering. Om Difi skal spille en sentral rolle i dette arbeidet må først Difi fornyes! Det ville vært ganske oppsiktsvekkende om den nye regjeringen bidrar til å institusjonalisere en gammel, stiv og forkastet modell.

Posted on February 21, 2014 at 11:32 am by gamsjo · Permalink
In: kontrakt, Kvalitet, ledelse, Planlegging, prosjektledelse, Samfunn · Tagged with: , , , , , , ,

30 Responses

Subscribe to comments via RSS

  1. Written by espen
    on 21/02/2014 at 12:25 pm
    Reply · Permalink

    Største problemet i det offentlige er at politikerne som styrer har veldig kortsiktige horisonter og er veldig opptatt av umiddelbar gevinst. Hver gang det er valg, trengs det resultater. Denne kortsiktigheten gjør at man f.eks hiver penger til store prosjekter. Det er roten til alle de håpløse prosjektene.
    Politikere som viser handlekraft, for å oppnå media/velgernes gunst, ved å strø ut store pengesummer. Mottager føler seg forpliktet til å gjøre noe stort, fordi de har fått store summer. Slik fortsetter den onde spiralen.

    F.eks i Politiets tilfelle burde man sakt, her er 5 millioner. Løs ett problem også tatt det ett problem av gangen. Det fungerer dårlig med at man trenger popularitet hvert andre år og hver gang media slår opp en sak.

    Politikere som kun ser på kortsiktig genivst er problemet, på samme måte som eiere i private selskap som kun har fokus på børskurs.

    • Written by gamsjo
      on 21/02/2014 at 1:13 pm
      Reply · Permalink

      Du har helt sikkert rett i at slike krefter stimulerer til store prosjekter og store leveranser, Espen.
      Men som skattebetaler og samfunnsborger kan jeg ikke bare slå meg til ro med denne vettløse sløsningen.

      Jeg tror løsningen kan være å begynne litt på siden av de virkelig store flaggskipprosjektene. Der ligger det mye bedre tilrette. Men da må først Difi og andre forstå at det må finnes et reellt alternativ – og lage en smidig veiviser som er helhjertet. Så får vi se på sikt om erfaringene fra de mindre satsningene er så gode at det vil tvinge seg fram også i de store..

  2. Written by Harald
    on 21/02/2014 at 7:52 pm
    Reply · Permalink

    Tror fossefallsmodellen appellerer organisasjonskulturelt til ledere i offentlig sektor fordi en videreføre arbeidsform med mange møter, hvor sluttproduktet er dokumenter til neste runde i planlegginga. Går det skjeis kan en skylde på leverandøren eller at at det skulle vært planlagt enda mer.

    En arbeidsform med prototype, brukertest, forbedring, betatesting, ny versjon, ny brukertest ….. vil være et kultursjokk. Da er det jo mer behagelig å videreføre en byråkratisk metodikk enn å endre den.

    Hvorfor feiler it-prosjekter?
    http://www.bekkelund.net/2014/02/10/hvorfor-feiler-it-prosjekter/

    • Written by gamsjo
      on 21/02/2014 at 10:33 pm
      Reply · Permalink

      Tror du har rett i dette, Harald. Mange krefter vil bevare det bestående. Og en iboende egenskap med vannfallsmodellen er jo at det alltid er noen andre (roller) å skylde på.
      Men den største ulempen med smidig er kanskje at det blir behov for færre ledere, koordinatorer og byråkrater..

  3. Written by Christian Hauknes
    on 21/02/2014 at 8:47 pm
    Reply · Permalink

    Det er mye i prosjektveiviseren jeg er uenig i og som det hadde vært interessant om smidig-miljøet utfordret faglig, men denne kritikken synes jeg faktisk blir overfladisk og tabloidisert.

    For det første er det viktig å huske at mange (jeg vil tippe de fleste) IT-prosjekter i det offentlige ikke er produktutviklingsprosjekter. Og felles for både Google, Amazon, Facebook, eBay, Yahoo, Salseforce.com, Spotify og FINN.no er at de ikke utvikler støtteverktøy til standardiserte prosesser som skal kjøres på tvers av geografi, og med mange interessenter og eierskap lokalt. Det gjør man mye av i det offentlige.

    I slike settinger så er det faktisk mye fornuft i fasemodeller og eksplisitte, dokumenterte avgjørelser. Skal du starte noe som skal rulles ut over en hel organisasjon, så skal det være veldig klart, eksplisitt og forstått hva det er prosjektet skal gjøre, hva målet er, hvem som eier dette, hvem som tar avgjørelser, hvem som skal uttale seg, etc. Jo mer komplisert organisasjon og endringen er, jo viktigere er det å få dette skrevet ned veldig presist og signert i blod av alle som sitter i en posisjon hvor du må ha støtte. Gjør du ikke jobben din godt nok her, så kommer sklitaklingene fra sidelinjen susende inn når man skal begynne å levere og endret noe, og hele initiativet havarerer.

    Og selv i et utviklingsprosjekt i en slik setting, er det fornuftig med en planfase. Du trenger ofte en styringsgruppe som er riktig sammensatt for å kunne eskalere avgjørelser underveis. De personene der, er neppe eksperter på smidig gjennomføring. De skal forstå hva det er de er med på, hvordan man skal styre, forholde seg til endringer, hva man skal planlegge tidlig, hva man skal ta av avgjørelser underveis, etc. Hopper du over det, så kan du kjøre så smidig du bare vil, men du vil tape tillitt underveis fordi man ikke har sørget for at ”stakeholderne” dine forstår hvordan prosjektet skal kjøres.

    I ”gjennomføringsfasen” kan man kjøres smidig som F, men en eksplisitt overlevering fra prosjekt til linje er fornuftig i en stor organisasjon. Nye folk skal ofte inn i roller og ta ansvar de ikke har hatt før, og det skal man ta seriøst, og planlegge og forankre.

    Å spesifikt planlegge gevinstrealisering i slike settinger er også meget fornuftig. Systemet som er utviklet leverer sjelden verdi i seg selv. Noen skal ha ansvaret for å følge opp at man faktisk får verdi ut av den nye prosessen. Man skal tenke på hvordan det skal måles, hvem som skal følge opp, hvem som har mandat til å bestemme endringer på prosess (ikke nødvendigvis system, men hvem som gjør hva, hvordan det gjøres, etc). Alt dette er viktig for å faktisk få nytte av leveransen. Har man jobbet en del med Lean og prosessforbedring, så er dette åpenbart, så det overrasker meg at smidig-miljøet ikke aktivt omfavner en slik fase, og jobber for at den fylles med et fornuftig innhold.

    Det er mye i det som ligger under hver fase i prosjektveiviseren som man burde diskutere (og kritisere). Men å kategorisk angripe fase-modellen med henvisning til ”lokomtivene i IT-bransjen”, så beviser man at man faktisk ikke forstår at de fleste prosjekter i store organisasjoner dreier seg om mye mer enn produktutvikling og short time to market. Og da gjør man det enda vanskeligere å få lov til å ta i bruk smidig metodikk i prosjekter i offentlige (og andre store) organisasjoner.

    • Written by Benjamin
      on 21/02/2014 at 10:14 pm
      Reply · Permalink

      Hei Christian,

      Takk for at du deltar i debatten. Jeg er medforfatter av artikkelen i DN og kollega av Geir i Axio.

      Store selskaper som Google, Amazon, Facebook, eBay, Finn.no etc utvikler jo nettopp støttesystemer til standardiserte prosesser som er egnet for å kjøres på tvers av geografi. Det er jo kjernen i suksessen de har hatt – de har brukt smidige tilnærminger for å lære raskt og lytte til tilbakemeldinger fra brukeren.

      Jeg har selv kjørt store smidige prosjekter med rapportering til styringsgrupper. Smidig gir ypperlige vilkår for diskusjoner rundt prioriteringer, målet med prosjektet etc. Dette er verdifulle styringssignaler – forskjellen mellom vannfall og smidig er jeg har hatt anledning til å rapportere tilbake til styringsgruppen om hvordan brukerne tar i bruk (eller ikke tar i bruk) ny funksjonalitet og løsninger. Dermed ser man også fort om man kan få de forventede gevinster ut av prosjektet. Dette bidrar også til at et produktutviklingsprosjekt, ikke bare er det – men også er et organisasjonsutviklingsprosjekt der organisasjonen får ny innsikt både om seg selv og sine brukere (det være interne eller eksterne).

      • Written by Christian Hauknes
        on 22/02/2014 at 10:24 pm
        Reply · Permalink

        “Google, Amazon, Facebook, eBay, Finn.no etc utvikler jo nettopp støttesystemer til standardiserte prosesser som er egnet for å kjøres på tvers av geografi.” ????

        Støtter Facebook en standardisert prosess? Er de avhengige av at brukerne i Skottland gjør ting likt som de i Portugal? Ruller de ut prosesstøtte på tvers? Hvis finn-brukerne i region øst mener den nye endringen er skadelig, klager de da til sjefen sin, som igjen ringer inn sentralt og forklarer at dette er noe dritt som kommer til å sette liv og jobber i fare, og slik torpederer hele prosjektet?

        Jeg har også kjørt flere smidge prosjekter med rapportering til styringsgrupper, og jeg sitter i styringsgrupper til flere store smidige prosjekter. Og jeg har sett prosjekter som har gått opp i problemer og som jeg ser håndterer de problemene eksemplarisk bli skutt ned fordi prosjektet ikke har greid å forklare hva de driver med, hvordan de styrer, og hvordan de reduserer og kontrollerer risiko. Og jeg har sett gode prosjekter og initiativer bli torpedert fordi de har startet for fort, uten å ha alle stakeholdere om bord når toget startet, men latt de få lov til å stå på sidelinjen og se på og komme susende inn fra siden når det begynner å bli alvor.

        • Written by Benjamin
          on 24/02/2014 at 4:00 pm
          Permalink

          Hei Christian,

          La oss begynne med det vi er helt enige om – det er nødvendig å ha en kompentent styringsgruppe som også har noe kunnskap om smidig. Derfor anbefaler vi alltid å også gi nødvendig informasjon til interessenter og ledelse som er i randsonen av et smidig prosjekt.

          Når det gjelder de andre delene av kommentaren så blir jeg fylt med mange spørsmål. Kommetarfeltet er en dårlig arena for en god diskusjon rundt disse andre kreftene så det får vi ta en annen gang ☺

          Med Facebook og Finn.no etc er det jo slik at om du eller jeg skal gjøre en statusoppdatering eller legge inn en annonse så må vi gjennom den samme prosessen.

  4. Written by gamsjo
    on 21/02/2014 at 9:30 pm
    Reply · Permalink

    Hei Christian, tusen takk for veldig konstruktiv kritikk!
    Jeg er klar over at dette er tabloid, du skal vite at jeg har forsøkt å lokke fram en slik debatt med litt mildere midler. Uten respons. “Tie ihjel” synes å være en taktikk som funker…

    Jeg forstår ikke like godt som deg hvordan de store offentlige systemene virker, men jeg skjønner at det er områder og initiativer der vannfallsmodellen fungerer godt. Jeg sier jo også i artikkelen:
    “Dette kan fungere godt for en del typer prosjekter, men er særdeles lite egnet for kunnskapsintensivt, dynamisk og innovativt arbeid som programvareutvikling vitterlig er.”
    Så jeg addresserer først og fremst ren programvareutvikling.

    Du vet like godt som meg at vi ikke har noe imot forarbeide og planlegging – og ikke minst å planlegge gevinstrealisering i smidige utvikling. Men poenget er å ikke låse planen. Suksess dreier seg om å nyttiggjøre seg det man lærer underveis. Derfor kan du gjøre *mindre* forarbeide uten at du øker risikoen. Og du *skal* realisere gevinstene underveis og ikke bare på slutten. Man bør helt eksplisitt si at man skal unngå de store leveransene og et komplett scope.
    Les gjerne forrige blogpost “kunsten å planlegge det ukjente” http://scrummaster.no/2014/kunsten-a-planlegge-det-ukjente/. Leser du enda mer på bloggen min ser du at jeg personlig er veldig opptatt av planlegging.

    Du har helt sikkert et poeng i at “smidig-miljøet” i for liten grad omfavner dette forarbeidet. Jeg tror kanskje litt av forklaringen ligger i at vi som regel ikke møtes av noen åpen debatt. I stedet blir det for innadvendt og mye fokus på å angripe “vannfall” – og jeg innrømmer at prosjektveiviseren ble en kjærkommen anledning til dette.

    Jeg mener de store organisasjonene kan profitere mye på en mer smidig *tankegang*: Lage minimumsløsninger først i stedet for å klompe sammen en stort scope der alt er like viktig. Jobbe i korte iterasjoner og levere ofte for å stimulere til læring – ikke bare for time-to-market. Og å skape gjennomsiktighet fremfor komplekse prosjektstyringssystemer. Dessuten å skape dedikerte, gode team som får snakke direkte med brukerne. Løpende. Det er mange fordeler med smidig, men det har ikke bare med vannfall kontra iterasjoner å gjøre.

    Det blir for dumt å kjøre “smidig som bare F” i gjennomføringsfasen om man har svidd av to år på å lage fantastiske spesifikasjoner og planer som ikke lenger er aktuelle. Dette skjer sikkert ikke i Statkraft, men i store deler av offentlig sektor er dette virkeligheten. Hvordan skal Difi stimulere til å gjøre tilstrekkelig forarbeide, men heller ikke mer? Hvordan skal Difi stimulere til læring og til å realisere gevinster løpende? Dette skjer i hvert fall ikke med prosjektveiviseren.

    • Written by Christian Hauknes
      on 22/02/2014 at 10:08 pm
      Reply · Permalink

      Hei Geir,

      For ordens skyld: Jeg snakker som privatperson, og ikke på vegne av min arbeidsgiver.

      Du kjenner meg godt nok til å vite at jeg ikke tror løsningen er å svi av to år på fantastiske spesifikasjoner. Og her ligger poenget mitt: Det er mye som burde kritiseres i prosjektveiviseren. Innholdet som ligger i flere av stegene er ikke fornuftig og vil føre til store oppblåste prosjekter. Dette er det man burde angripe faglig, ikke at man har spesifikke, klare faser – det er faktitisk nødvendig i store, komplekse organisasjoner. La oss heller sørge for at innholdet i de fasene er formålstjenelig.

  5. Written by gamsjo
    on 23/02/2014 at 8:00 am
    Reply · Permalink

    Hei igjen Christian,
    jeg vet selvsagt at *du* ikke ville finne på å svi av to år på spesifikasjoner. Men det er ikke poenget, det interessante er hva slags adferd veilederen stimulerer til. De færreste har din forståelse..

    Du sier “La oss heller sørge for at innholdet i de fasene er formålstjenelig.” Vel, jeg kan være enig i det, når det gjelder de tidlige fasene. Men at gevinstrealisering er en fase som kommer til slutt, er anti-smidig og et effektivt hinder for verdifull brukerinvolvering og læring underveis. Hva mener du om dette?

    Jeg vet du har hatt mange ulike roller og vært involvert i mange prosjekter. De du kaller smidige prosjekter, har de *prodsatt* i iterasjoner, eller bare levert til test? Jeg tror det er viktig å være presis her, for at diskusjonen skal fungere godt..

    • Written by Christian Hauknes
      on 24/02/2014 at 5:52 pm
      Reply · Permalink

      Hei Geir,

      Ang. releaser:
      Det varierer veldig. Fra et produktperspektiv er det klart at man vil release så ofte som mulig – bare fordeler, ingen ulemper. Så der jeg har jobbet med f.eks nettbaserte produkter sluppet til mange brukere har vi prodsatt hver iterasjon.

      Når du leverer systemstøtte til prosesser, så er problemstillingen fort litt annerledes. Ofte vil en endring i et system medføre en endring i arbeidsprosess. Hvis brukergruppen din er liten og samlokalisert, så kan du ta mindre steg og ha tilstrekkelig kontroll, og derfor release relativt ofte.

      Er brukergruppen stor og spredd geografisk, så er det ofte ikke formålstjenelig å gjøre små endringer. Hver endring i system som medfører endring i arbeidsprosess må fort rulles ut med tilstrekkelig endringshåndtering i linjen (altså blandt brukerene). Det må fort også testes og verifiseres på tvers av geografi, som igjen er arbeidskrevende og belastende for linjen. Selv små endringer krever rett og slett et lite endringsprosjekt. Da kan man ikke release for ofte. Så selv om det fra et utviklingperspektiv hadde vært å foretrekke, så koster det for mye og sliter på organisasjonen som bruker systemet.

      Ang. gevinstrealisering:
      Jo før, jo bedre, selvsagt. Og der gevinstrealisering skjer mer eller mindre av seg selv ved å slippe en ny versjon av produktet, så er det en no brainer.

      Men i store organisasjoner så er min erfaring at produktet / systemet bare er en liten del av gevinstrealiseringen. Den endringen som virkelig genererer verdi er endring av prosessen / arbeidet som utføres. Dette skal forbedres og følges opp over tid, også etter at endringsprosjektet er over.

  6. Written by Camilla Grøneng
    on 24/02/2014 at 12:57 pm
    Reply · Permalink

    Det er mange interessante poeng som løftes i denne diskusjonen, og Christian har absolutt rett i at smidige metoder ikke nødvendigvis passer fenomenalt godt inn i de store organisasjonene vi finner i offentlig sektor.

    Jeg har lyst til å peke på en annen årsak til at “verden er slik som den er” i det offentlige Norge, med lange, usmidige prosjekter og stadige utfordringer med de store IT-prosjektene. Jeg tror nemlig det handler mye om hvor pengene kommer fra, og hvilke ringer vi må hoppe igjennom for å få tildelt budsjetter for å gjøre noe som helst.

    Ta for eksempel de virkelig store IT-prosjektene, de som krabber over 500 MNOK. Her stiller Finansdepartementet krav til kvalitetssikringsprosesser som krever nettopp den “grundigheten” en vannfallsmetode bygger opp under. Man skal, gjennom konseptvalg (KS1) og styringsdokument med tilhørende estimater (KS2) gjøre rede for nøyaktig hva man har tenkt å lage, og hvor mye det vil koste. Denne øvelsen krever – dessverre – en forholdsvis nøye gjennomgang av omfang med spesifisering av de enkelte elementer. Man kommer ganske enkelt ikke unna, selv om de fleste som jobber i bransjen er klar over at det sjeldent er noe 1:1-forhold mellom det som blir beskrevet i disse fasene og det som faktisk blir levert – til tross for at alle gevinster behørig er dokumentert og beskrevet i styringsdokumentet.

    Til alt overmål skal det gjerne bevilges penger over statsbudsjettet, og som tidligere kommentert av Espen; politikere vil gjerne vise seg handlekraftige, og vil ha alle detaljer på bordet før de bruker av velgernes penger. Det skulle da bare mangle, de er jo til å stole på!

    Resultatet er at om man ønsker å be om “en god slump penger” for å kunne gjennomføre et større arbeide, så må man levere noe som er troverdig nok til at Finansdepartementets kvalitetssikrere og bevilgende politikere føler seg trygge på at det planlagte arbeidet er grundig gjennomtenkt. Så får man heller ta unntakene og endringene underveis.

    Så kan man kanskje si at å kjøre de store prosjektene er å be om trøbbel, og man burde gjøre som i det private og ta bit for bit. Dette har mye for seg, og det er en veldig behagelig tanke å kunne prøve ut en god ide, levere litt verdi, og ha et godt forhold til produkteier (hvem det nå måtte være). Ved siden av argumenter om organisasjon og forankring Christian har vært inne på, er det minst to utfordringer til man må ta høyde for her.

    For det første dreier mange av de store prosjektene seg om å erstatte gamle systemer. Og det er ikke alltid like enkelt å gjøre dette bit for bit. Enten fungerer de, eller så gjør de det ikke. Det er ikke nødvendigvis så enkelt å bare skru av litt. Dette er selvfølgelig avhengig av hvilke systemer man snakker om, men jeg tror nok at de fleste som har vært innom et slikt prosjekt skjønner hva jeg snakker om her. Problematikk med sameksistens, integrasjoner mellom gammelt og nytt, mastring av data, delt funksjonalitet etc er stadig tilbakevendende problemstillinger – og det er dyre problemstillinger som man kan kaste nærmest uendelig mye penger etter uten at de løser seg spesielt elegant av den grunn. I tillegg er ofte organisasjonen ukomfortabel med tanken på å skulle leve med “litt av det ene og litt av det andre” i sine arbeidsprosesser, og krever at om man først skal fjerne det gamle systemet så skal det nye kunne ta over alle oppgavene i alle fall innenfor en gitt prosess. Slike utfordringer gjør at det ofte blir mer eller mindre store “jafs” som må tas om gangen, med produksjonssettinger årlig eller halvårlig (i beste fall).

    Den andre utfordringen man ofte treffer på i forsøket på å unngå kjempeprosjektene, er at det er en evig kamp om budsjettene for små prosjekter og løpende videreutvikling. De store prosjektene gjør jo nettopp en hel masse jobb for å bevise at de trenger mye penger; de små prosjektene finansieres ofte over den den enkelte organisasjonsenhets budsjetter. Og budsjetter skal jo, som vi alle vet, stadig krympes. Konsekvensen er at om man ikke er stor nok til å gå utenfor (det vil si egne bevilgninger), så må man sloss om de begrensede budsjettmidlene som finnes. Og ikke nok med det… (litt tv-shop-selger her, kjenner jeg…) Budsjettene legges jo et år i forveien, så innspill til budsjett bør helst skje halvannet år før man har tenkt å faktisk gjøre noe. Er det noen som begynner å grøsse litt nå? Ikke er det så enkelt som at man sier at man tror man trenger noen penger til et ikke-spesifisert utviklingsløp, heller – tommelfingerregelen er at alt som er stort nok til å kreve et prosjekt, må inn på IKT handlingsplan eller hva man nå måtte kalle de store leveranseplanene. Og da skal det være godt nok gjennomarbeidet og beskrevet til å vite ikke bare hvor mye det vil koste, men hvilke konsekvenser det vil få for omkringliggende systemer og infrastruktur, og når det skal utvikles, testes og releases. Igjen, penger og planlegging.

    Okay, det ble en lang “rant”. Men dette er problemstillinger vi ser igjen og igjen; smidig metode, som beviselig fungerer som programvareutviklingsmetodikk hos mange av de store i bransjen, passer ikke nødvendigvis helt inn i det offentlige, verken med tanke på organisasjonskultur eller budsjetterings- og styringsprosesser. Så hva gjør vi? Tja, vi gjør vel som vi alltid har gjort, vi prøver så godt vi kan innenfor de rammer vi er nødt til å forholde oss til.

  7. Written by Niklas Bjørnerstedt
    on 24/02/2014 at 7:09 pm
    Reply · Permalink

    Jeg tror Camilla er inne på noe her. Det er randvillkårene som avgjør hvor smidig du kan være. Hvis det er mange interessenter og ingen klar beslutsstruktur, krav om samtidig utrulling i hele landet, +++ så har Christian på en måte rett. Det han beskriver som løsning kan (litt slemt) kalles en “bordet fanger prosess” der alle skriver under på hva som skal lages og ikke kan sabotere prosjektet senere. Dette er en prosess som dessverre vil produsere et mediokert system som alle parter tvinges å ta i bruk siden de har være med på specen.

    Alternativet er å utfordre disse absolutter. Kan vi rulle ut til en liten gruppe brukere først? Kan vi se bort fra de fleste interessenter i først omgang?

    I staten er svaret ofte nei, randvillkårene er hellige. Konklusjonen av det er at staten ofte er dømt til å kjøre dyre, ineffektive prosjekt med et medioker resultat.

    • Written by Christian Hauknes
      on 25/02/2014 at 7:56 am
      Reply · Permalink

      Dette mener jeg er en misforstått forenkling. Å ha en tydelig, eksplisitt konseptfase hvor interessenter signerer ut resultatet betyr ikke å få alle til å skrive under på hva som skal lages. Da har man gjort det feil, og tatt avgjørelser på feil tidspunkt.

      Det er andre ting det i en stor organisasjon er viktig å få forankret i en slik fase; Hva er problemstillingen vi skal løse? Hva er målsetningen? Hvilke valg må vi ta tidlig, og hvilke er det vi skal ta underveis? Hvem får lov til å ta de avgjørelsene? Hvem skal få uttale seg underveis, og når? Hvem er ansvarlig for at det skjer? Hvordan skal vi kjøre løpet?

      Det er spørsmål man bør sørge for at alle er enige om og gjerne skriver under på. Da sørger man for at alle er med på toget når det går, og at ingen får lov til å stå på sidelinjen og se på.

      Dette dreier seg om å skaffe de rette rammebetingelsene til prosjektet. Det skjer ikke av seg selv. Da er eksplisitte faser for konsept og plan viktig.

  8. Written by Christin
    on 24/02/2014 at 9:22 pm
    Reply · Permalink

    Folkens, vi lever i et demokrati. Våre lover, regler og prosesser er ikke skrevet i stein, de kommer ikke fra høyere makter, men fra oss selv gjennom våre folkevalgte politikere. Prosesser som omhandler utvikling av IT-systemer kan umulig sees som spesielt hellige da de beviselig ikke fungerer spesielt godt. Vi kan ikke unnskylde oss med at “sånn er det bare” hvis vi genuint mener det ikke er bra nok. Jeg synes søren meg det er vår plikt, som professionelle IT-folk, å endre statens praksis slik at skattepengene kan brukes til mer fornuftige ting enn overbyråkratiske software prosesser som fører til ubrukelige systemer.
    Kommer dette til å være lett? Nei. Kommer det til å ta tid? Ja. Men har vi virkelig noe bedre alternativ? Skal vi bare fortsette å leve med prosesser vi VET ikke funker? Fordi ingen har baller til å gjøre endringer?
    La oss i det minste sette det som et mål at der vi klarer å bryte ned problemene i helt konkrete “stand alone” produkter, så gjør vi nettop det. Så jobber vi etter smidige prinsipper i utviklingen av disse produktene. (da mener jeg faktisk smidig – ikke smidig som i “ja, vi har stand up møte hver dag i gjennomføringsfasen”-smidig.)
    Det kan da umulig være et spesielt ambisiøst mål? Vi får til det?

  9. Written by gamsjo
    on 25/02/2014 at 7:24 am
    Reply · Permalink

    @Christin – du satt ord på akkurat det jeg også tenker!

    Er litt nedsylta i kurs og greier, så jeg rekker ikke å svare alle, men jeg skylder @Christian, @Camilla og @Niklas svar. Her kommer et felles svar:)

    Det enkleste som fins er å liste opp alt som hindrer oss i å ta grep og forandre på ting. Likte TV-shop- bildet ditt Camilla. Det er ikke uten verdi å være bevisst på alt som hindrer oss i å gjøre det riktige, men det behøver ikke å gjøre oss handligslammet. Som dere alle er inne på det er enorme forskjeller også i det offentlige, og det finnes opplagt områder der systemene er svært komplekse (og med mye teknisk gjeld) og de politiske prosessene stikke kjepper i hjulene for god smidig tankegang. Og jeg ser at det er vanskelig å bytte ut systemer som er i full drift bit for bit.

    Men jeg insisterer på at det i det offentlige er akkurat som i det private: Det koker ned til *vilje*. Selv i FINN.no var det i 2006 stor skepsis til å begynne å release oftere enn 3-4 ganger i året. Lista over hindringer var lang. Vi kan smile av dette i dag.

    I stedet for å si “Det er randvillkårene som avgjør hvor smidig du kan være.” så må vi heller finne de som er ansvarlig for disse vilkårene og forsøke å snakke med dem. Finansdepartementet har grunner for hvorfor de kjører dette budsjettspillet. En av grunnene er å redusere risiko. Så spørsmålet er “Hvem skal fortelle finansdepartementet at denne budsjetteringspraksisen på IKT fører til høyere og ikke mindre risiko?” Eller mer generelt: Hvem skal fortelle de rette miljøene at ved å gjøre *mindre* forarbeid (og løse problemer i iterasjoner) kan få langt lavere risiko – i tillegg til at det blir billigere, med høyere gevist? Noen må initiere prosesser langt utenfor ren IKT for at det skal bli endring. Og som Christin sier, dette vil ta lang tid.

    Jeg tror det vil tvinge seg fram før eller siden, og skyen vil gi muligheter, der det i dag virker veldig vanskelig.

    Problemet i dag er ikke Prosjektveiviseren i seg selv, men snarere at det ikke finnes noe helhjertet Smidig alternativ! De som virkelig har lyst til å høste gevinstene av smidig er i stor grad overlatt til seg selv. Det funker jo her og der, men det er fordi det er ildsjeler der med stor vilje og kompetanse. Men det sprer seg ikke på den måten – selv om det er overlegent!

    Takk for alle bidrag så langt! Bare fortsett, vi skal på en eller annen måte lage mer ståhei rundt dette temaet:)

  10. Written by Camilla Grøneng
    on 25/02/2014 at 11:00 am
    Reply · Permalink

    Amen til det, Geir, Noen ™ bør snakke med Finansdepartementet (og andre som setter rammevilkår, for eksempel Difi) om dette. Og denne noen er nok antakelig oss som jobber med disse problemstillingene og kjenner dem på kroppen.

    For øvrig tror jeg Christian er inne på noe veldig viktig når han snakker om å få forankret tidlig hvilke problemstillinger man skal løse, og ikke minst NÅR de ulike beslutningene må tas og hvem som skal ta dem. Det er alltid mye lettere å jobbe med klare beslutningsstrukturer rundt seg. Har man gjort denne jobben bra i konseptfasen er den faktisk veldig verdifull. Motsetningen (og der vi ofte ender opp) er situasjonen der ingen tør å ta en avgjørelse, men alle ønsker å mene noe om den. Her snakker vi tidstyv…

    Jeg har også lyst til å si at det egentlig ikke er SÅ svart-hvitt som det kan se ut. Joda, det høres fryktelig ut med utviklingsprosjekter som går over mange år basert på en tidlig konsept- og planleggingsfase der detaljene hamres ut og estimeres til den store gullmedalje. Men sannheten er jo at verden forandrer seg, og jeg har enda til gode å se et “ferdig produkt” som er 100% likt det man trodde man skulle lage da man startet. Når prosjektet først er i gang, er man ofte overraskende klar for å gjøre nødvendige tilpasninger underveis, ingen ønsker seg jo et sluttprodukt som ikke fungerer som det skal. Problemstillingen er derfor ikke fullt så mye at man kjøper seg en tvangstrøye, men heller at man kanskje bruker unødvendig mye tid på detaljering og estimering i tidligere faser for å få midler til å starte utviklingsprosjektet. Og det er tid man heller kunne ha brukt på å etablere effektive beslutningsstrukturer (inklusive en plan for hvilke valg man må ta når) og forankre ansvar og myndighet.

  11. Written by Niklas Bjørnerstedt
    on 25/02/2014 at 2:43 pm
    Reply · Permalink

    Christian, det er mulig flere av oss har misstolket deg, men det spørs om ikke det delvis er på grunn av måten du formulerer deg. Jeg tror alle er enige om at det er kan være bra å definere de overordnede målene for et prosjekt før man starter det (det finnes unntak). Det er også bra å avklare en del andre randvillkår tidlig. Det som er farlig med Difis fremstilling er at det ikke finnes en synlig forskjell mellom modellen og et klassisk fossefallsprosjekt. For deg er det opplagt at man ikke skal skrive en detaljert spesifikasjon først. Det er neppe opplagt for de fleste prosjektledere i offentlig sektor. For deg er det opplagt at man bør få deler av løsningen i produksjon tidlig.
    Jeg skal holde foredrag på Software konferansen på torsdag og en av de ting jeg vil ta opp er det at smidige prosjekt SKAL begynne utvikle på ufullstendig og delvis feilaktig informasjon. Det er en absurd tanke for mange prosjektledere.

    • Written by Christian Hauknes
      on 26/02/2014 at 10:54 pm
      Reply · Permalink

      Hei Niklas,

      Jo da, erfaring sier at det er fult mulig at det er mine formuleringer som er problemet når det er misforståelser. Men tror du kanskje det er en bitteliten mulighet for at man faktisk ikke har prøvd å forstå argumentene som er skrevet, men bare sett noe om eksplisitte faser og da bestemt seg for hva man syns om slikt?

      Bortsett fra Camilla er det ingen som har referert til noe jeg faktisk har skrevet – andre virker å bare anta hva jeg må mene, og repetert gamle argumenter for smidig vs. vannfall, argumenter som både jeg (og jeg tipper alle andre som har kommentert her) kjenner godt og er enige i.

      Poenget mitt er: Artikkelen som Geir og Benjamin har skrevet angriper prosjektveiviseren basert på at de “store programvarelokomotivene” gjør dette annerledes, og at slike fasemodeller er gammeldags og unødvendig. Jeg mener den kritikken er faglig feil, fordi scopet for prosjektveiviseren ikke primært er programvareutvikling, men “gjennomføring av digitaliseringsprosjekter i offentlige virksomheter”. Jeg vil tippe at mange av disse ikke inneholder programvareutvikling i det hele tatt (men f.eks bruk av hyllevare), og selv for de som trenger noe programvareutvikling så er det ikke nødvendigvis den mest komplekse eller viktigste problemstillingen i prosjektet.

      Min erfaring sier meg at i slike prosjekter er det andre ting enn systemet / systemutviklingen som er vanskeligst i prosjektet og viktigst for verdiskapningen. Andre problemstillinger:
      • felles problemforståelse og felles målsetning på tvers av geografi og organisasjonsgrenser
      • Enighet om mandat og roller (hvem kan beslutte hva og representerer hvem) på tvers av geografi og organsiasjonsgrenser
      • forståelse og utrulling av nye prosesser (arbeidsprosesser altså, ikke IT-prosesser) på tvers av geografi og organisasjonsgrenser
      • prosesseierskap, mandat og ansvar for forbedring i linja etter prosjektet
      • Ansvar for verdirealiseringen (f.eks: når man effektiviserer, så blir fort noen overflødig. Hvem skal håndtere omskolering, evt. Nedskalering.)

      For å lande disse tingene og få alle med seg, så er det nødvendig med en meget ryddig prosess, med klare og eksplisitte avgjørelser. Eller faser om man vil.

      Jeg mener at man i denne artikkelen sitter med skylapper på, ser alt kun fra sitt ståsted (programvareutviklingen), ser ikke de andre og ofte viktigere problemstillingene i slike prosjekter, og da bommer kritikken. Derfor mener jeg at en argumentasjon som i artikkelen vil gjøre det vanskeligere for de i offentlig sektor som ønsker å bruke smidig filosofi og metodikk i prosjekter, og ikke enklere.

      På høyeste nivå (den figuren som er inkludert i artikkelen), mener jeg prosjektveiviseren treffer godt og er fornuftig for den type prosjekter den er ment å brukes for. Men kikker du på innholdet på nivået under (altså beskrevet praksis inne i de forskjellige fasene), så er det mye der som vil sende alle prosjekter rett inn i alvorlig trøbbel og alle “fossefallsfeller” som nevnes kan. Det er det vi burde diskutere og forsøke å bidra til å forbedre.

      Vi må huske at en smidig eller Lean filosofi ikke nødvendigvis betyr samme metodikk for forskjellige problemer. Tenk f.eks på at ”tradisjonell” lean (fra manufacturing, eller for den saks skyld service – tenk systems thinking) i svært stor grad fokuserer på standardisering av arbeid. I mer kreative prosesser (som systemutvikling), så er det fokuset ikke nødvendigvis formålstjenelig.

  12. Written by Niklas Bjørnerstedt
    on 27/02/2014 at 7:11 pm
    Reply · Permalink

    Ok, la oss droppe “hvem har feiltolket hvem” leken. Det viktige er jo at vi er litt mer enige. Her er noen kommentarer til det du ellers skriver. Jeg er ikke enig i at softwareutvikling er en liten del av de fleste digitaliseringsprosjekter. Jeg vet at en av de strategiske risiko flere av de store softwareutviklingshusene jobber med er faren for å ende opp med kun offentlige kunder. (hvorfor dette ses på som en risiko er en annen diskusjon). Jeg har også sett et antall digitaliseringsprosjekter i offentlig regi. Disse har inneholdt mye systemutvikling selv om kjernen kan være et “standardsystem”.

    Problemet med Difi er uansett at de tror at én modell passer til alle typer av offentlige digitaliseringsprosjekter. Skal du innføre ren hyllevare kan en faseinndelt prosess være fornuftig. Den er ikke fornuftig når et helt nytt saksbehandlingssystem skal lages.
    På Software konferansen i dag kom en representant fra Difi og prøvde mer eller mindre å kuppe Geir sitt foredrag. Det morsomme var at han i sin 5 minutters utlegging om hvor feil Geir var, klarte å motsi seg selv. Først la han ut om at Geir måtte forstå at rammebetingelsene i staten gjør at man må jobbe faseinndelt. Deretter hevdet han at Difis modell åpnet for en fullt ut smidig tilnærming… Jeg aksepterer at noen utviklingsprosjekter har rammebetingelser som gjør at de ikke kan kjøres særlig smidig. Da bør man heller ikke late som at de er smidige.

  13. Written by Christin
    on 27/02/2014 at 11:27 pm
    Reply · Permalink

    Bra og viktig debatt. Såvidt jeg har fått med meg, er alle enige at fossefall egner seg dårlig til software-utvikling. Debatten dreier seg nå om hvorvidt den kan brukes i prosjekter der software-utvikling kun er en liten del av hele prosessen. Christian, du nevner noen punkter som ikke er en direkte del av software-utviklingen, men som du mener best løses med prosjektveiviseren. Jeg er faktisk ikke enig med deg. Jeg tror selv disse problemene, vil bli bedre løst med en smidig tilnærming. Jeg har kopiert inn det du ser som ikke-software-problemer best løst med fossefall, så kommentert hvert punkt.

    • felles problemforståelse og felles målsetning på tvers av geografi og organisasjonsgrenser

    Men er det ikke ofte problemforståelsen og hva som egentlig er målsettingen på tvers av geografi og organisasjonsgrenser, som er noe av det som endrer seg etter planfasen er over? Jo vanskeligere og mer distribuerte problemene er, jo vanskeligere er det å få en fullgod oversikt før man starter. Jeg vil si at dette er et typisk eksempel på noe som ikke bør sees som låst før koding begynner.

    • Enighet om mandat og roller (hvem kan beslutte hva og representerer hvem) på tvers av geografi og organsiasjonsgrenser

    Igjen synes jeg dette er altfor viktig til at vi kan låse det før software-utvikling begynner. Jeg har opplevd at dette i stor grad handler om følelse av ryggdekning. Det kan være utrolig paralyserende. Ingen tør å gjøre noe, fordi ingen vil ha skylda hvis det går galt. Har man en person med en bestemt myndighet, må alt gjennom denne. Kjempeflaskehals. Det bør ikke være sånn, jeg håper det ikke er sånn for mange steder, men vet at det skjer flere steder enn det burde. Ved å levere ting med jevne mellomrom avdekkes det raskt om noen gjør dobbelt-arbeid, ikke godt nok arbeid, eller om ansvar bør fordeles på annen måte. Så lenge vi legger opp til en prosess der vi samkjører, har releaser, som blir testet og demonstrert ofte, så vil vi ikke trenge å være så opptatt av at absolutt alle roller og mandater er på plass fra dag 1.

    • forståelse og utrulling av nye prosesser (arbeidsprosesser altså, ikke IT-prosesser) på tvers av geografi og organisasjonsgrenser

    Ved å legge opp til at man ruller ut nye versjoner ofte til testing, vil dette bli mye enklere. De første releasene kommer til å gå dårlig, men så lærer man av sine feil.

    • prosesseierskap, mandat og ansvar for forbedring i linja etter prosjektet

    Ved å rulle ut versjoner i flere omganger blir denne prosessen også enklere og enklere. Innen alt er ferdig og alt prodsettes for alle, er man mye tryggere på at det kommer til å gå bra. I Husbanken tar vi både utvikling og forvaltning selv, prosjektet glir over i forvaltning og blir tatt hånd om av mange av de samme menneskene. Dermed blir «overlevering til linja» ikke noe nevneverdig problem. Jeg synes vi burde legge opp til at flere stalige instanser kan jobbe slik.

    • Ansvar for verdirealiseringen (f.eks: når man effektiviserer, så blir fort noen overflødig. Hvem skal håndtere omskolering, evt. Nedskalering.)
    Dette også er noe som kan tas fortløpende. Ettersom produktet blir mer og mer klart, blir det også tydeligere og tydligere akkurat hva slags kompetanse som vil bli nødvendig, og hva som ikke lenger trengs.

    Kort sagt er det ingenting du nevner her som jeg føler utelukker en smidig tilnærming. Tvert imot er det nettopp disse tingene som gjør at en smidig tilnærming er å foretrekke.

  14. Written by gamsjo
    on 28/02/2014 at 8:25 am
    Reply · Permalink

    Wow!

    Sitter litt på sidelinjen her og lærer og får a-ha opplevelser. Og jeg synes på en måte vi har kommet forbi prosjektveideleren nå. For meg ble denne et “kjærkomment” symbol på gammeldags tankegang. Et slags “fiendebilde” :) Men som Christian er inne på – på toppnivå er det ikke nødvendigvis noe galt med faser. I hvert fall ikke når det ligger en smidig tankegang i bunn. Og så lenge man ikke akkumulerer opp alt arbeidet til få store leveranser på slutten.

    Som Niklas sier kom Jens Nørve fra Difi opp på podiet og jeg må innrømme at jeg ble litt forfjemset og oppfattet nok ikke helt hva han sa. Jeg måtte avbryte ham faktisk, for tiden var egentlig ute. Men det jeg oppfattet var følgende:

    1. Intensjonene med prosjektveilederen var å være smidig – det var bare ikke kommunisert godt nok. Hmmm… Christin som var tilstede på det famøse seminaret 18 desember vil nok ikke være enig i dette. Og som jeg sa til Nørve: jeg har sett de 4 timene på video og ikke noe i den retorikken der tydet på smidig tankegang – bortsett fra de få minuttene Christin tok.

    2. Han inviterte til dialog. Jeg har sagt utallige ganger at jeg gjerne vil bidra til å lage en smidig veileder uten at dette fører fram. Kanskje Difi vil lytte nå? Jeg skal gjøre ett – 1 – nytt forsøk på dette.

    De punktene du tar opp er selvsagt viktig, Christian. Takk for at du tydeliggjør alle de ulike aspektene ved IT-prosjektene. Men jeg kan heller ikke se noen grunn til at disse tingene kan/bør ivaretas underveis på en smidig måte. At det lett kan bli motstand og frustrasjon når ubehagelige beslutninger skal fattes er selvsagt – og man må være ekstremt ryddig og bedrive forventningsstyring hele tiden. Ansvarsforhold må være krystallklare – men dette er jo virkelig ivaretatt med smidig tankegang!

    Jeg synes som sagt dette har utviklet til å bli en veldig konstruktiv og lærerik debatt. Vi får se om Difi vil forsøke å være relevante og delta i debatten…

  15. Written by Terje Heen
    on 03/03/2014 at 1:15 am
    Reply · Permalink

    Jeg har sittet og fulgt med på diskusjonen en stund, og fikk gleden av å få med meg innleggene til både Geir og Niklas under Software 2014. Jeg har også brukt 4 timer (!) av søndagen til å se igjennom videoen fra seminaret for å få en best mulig forståelse av hva som diskuteres.

    Aller først må jeg si at jeg selv er arkitekt/utvikler, og stor tilhenger av smidige metoder og de fordeler som det gir. Jeg har som konsulent deltatt på flere store og små prosjekter i det offentlige hvor smidig har blitt benyttet i varierende grad.

    Når det er sagt, så må jeg si meg enig i mye av det Christian sier. På høyeste nivå synes jeg prosjektveiviseren er OK.

    Jeg synes konsept og planleggingsfasen er viktig. Men det må holdes på et overordnet nivå. Her snakkes det om de overordnede målene til virksomheten, og en sammenligner ulike prosjektinitiativ opp mot hverandre og hvordan de kan realisere ulike gevinster (har ingen styreerfaring, men det er slik jeg tror og mener det bør være). Dette henger tett sammen med (eller er) virksomhetsstyring/porteføljestyring.
    Dersom denne jobben ikke gjøres ordentlig, vil dette fort føre til teknisk gjeld i virksomheten gjennom f.eks. flere produkter som fort løser samme problemer som igjen fører til unødvendige kostnader. Mangelfull styring vil heller ikke greie å synliggjøre reelle kostnader ved forvaltning av de systemene/produktene som en har.

    Jeg tror mye av utfordringen som Difi møter med prosjektveilederen er knyttet til kommunikasjon og hva slags referanser/bakgrunn den enkelte bruker/leser har. Det er med på å påvirke tolkningen av figuren og teksten.
    @Niklas: Du er inne på det samme når du sier; _Det som er farlig med Difis fremstilling er at det ikke finnes en synlig forskjell mellom modellen og et klassisk fossefallsprosjekt. For deg er det opplagt at man ikke skal skrive en detaljert spesifikasjon først. Det er neppe opplagt for de fleste prosjektledere i offentlig sektor. For deg er det opplagt at man bør få deler av løsningen i produksjon tidlig._
    Det å forstå viktigheten av å utsette detaljering så lenge som mulig, og å ha et aktivt forhold til kost/nytte tror jeg er essensielt, men jeg har også sett tilfeller hvor en har detaljert alt for mye, alt for tidlig. Det tar bort mye av nytteverdien ved smidig. Spesielt er dette bortkastet når noe blir valgt bort pga. for høye estimater og en allerede har brukt mye tid på detaljer.
    Innspill til Difi: Prosjektveilederen bør ikke nødvendigvis skrives av personer som har gjennomført smidige prosjekter. I stedet bør den skrives av andre, med hjelp av folk som har gjennomført smidige prosjekter. Da slipper en at den som skriver tar ting for gitt.

    Jeg kjenner meg godt igjen i den Smidige beskrivelsen av de ulike fasene, http://prosjektveiviseren.no/node/294/part/, med bakgrunn fra PERFORM-prosjektet hos SPK. Så vil noen henge seg opp i at prosjektet ikke leverte hyppig nok til produksjon for å være “ordentlig smidig”. Men det er ingen ting i prosjektveilederen som ikke sier at det hadde vært mulig etter hva jeg kan se. Det har mer med hvordan en ønsker å styre og realisere prosjektet sitt, og hvordan en greier å bryte opp delene som skal lages i “produkter” som @Christin er inne på. Dette er vanskelig, men sentralt om en ønsker å få til hyppige leveranser. Det vil også være med på å sette føringer for hva slags arkitektur en trenger.

    Det viktigste er tydelige mål av hva en skal oppnå, overordnede oppgaver som kan relateres tilbake til overordnede mål og som prioriteres etter kost/nytte, før de brytes opp og detaljeres og estimeres “i siste liten” før konstruksjon. Alt i tett dialog med forretning. Det gjelder også innenfor en sprint, hvor utvikler kan hente innspill fra forretning til å gjøre justering for et best mulig resultat. Dersom en skal prøve ut noe nytt, er det heller ingen ting som hindrer en i å gjøre prototyping dersom det godkjennes. Med litt rammer vil det fort kunne bidra til å redusere risiko.
    Ideelt sett synes jeg også prosjektdeltagerne bør få feedback fra produktet i produksjon kort tid etter at det er implementert. Det vil gi økt eierskap og bedre kvalitet, muligheten til å endre/tilpasse raskere, og om en er heldig kan en kanskje kaste ut noen av produktkøelementene som ikke lenger er like viktig, og hente ut gevinster tidligere enn først planlagt.

    Selv skulle jeg ønske det var mer fokus på produkt(ene) og forskjellen på prosjekt og linje/forvaltning. Min erfaring er at det alt for sjeldent snakkes om hvilke kostnader produktet vil ha etter at prosjektet er ferdig? Hva er de årlige kostnadene ved produktet, og hvor lenge skal produktet ha en funksjon? Da tenker jeg ikke bare på infrastrukturkostnader og lisenser, men også forvaltning av kodebasen (de resterende 80% av kostnadene).

    I prosjektveiviseren, http://prosjektveiviseren.no/avslutningsfasen/støtte-til-innføring-av-prosjektets-produkter-i-linjeorganisasjonen, snakkes det også om “når prosjektet har ferdigstilt de planlagte produkter” og skal overleveres linjen. Hva er et ferdig produkt? Det kan være at prosjektet er ferdig (fordi grensen for avsatt tid eller penger er brukt opp), men produktet har vel bare såvidt startet sitt liv?

    Beklager det lange innlegget, men sånn blir det når en samler opp og gjør en stor leveranse i stedet for flere små…

  16. Written by gamsjo
    on 03/03/2014 at 8:14 am
    Reply · Permalink

    Hei Terje, takk for (langt) fint innlegg i debatten:)
    Får vel takke det triste været for at folk tar seg tid til å se kjedelige videofilmer og skrive lange svar på søndagen.
    Når det gjelder signalene prosjektveilederen sender på høyeste nivå vil jeg si 3 ting:
    1. Den signaliserer at gevinstene skal realiseres på slutten og ikke løpende
    2. Den signaliserer at det er greit å klumpe sammen en diger leveranse (hvilket all erfaring tilsier er en dårlig strategi)
    3. Den signaliserer at vi skal gjøre som vi alltid har gjort. Altså ingen endring.
    Men som jeg har sagt mange ganger: Dette er greit, så lenge det finnes et *godt alternativ* for innovative, kunnskapsbaserte initiativer (jeg bruker bevisst ikke ordet prosjekter).

    Om noen ønsker å gjøre grep for at digitaliseringsprosjektene skal gå *vesentlig* bedre enn det vi er vant til må man lage en veileder som på høyeste nivå:
    1. Signaliserer tydelig at vi tenker å hente ut gevister raskt og løpende
    2. Signalisere at omfanget blir til mens vi jobber
    3. Signalisere tydelig at dette er noe vesensforskjellig fra tradisjonelle prosjekter.
    Den siste er viktigst; Jeg har jobbet med innføring av Smidig mange steder og det aller vanskeligste med dette er ikke forståelse av smidig, men derimot de endringene som er nødvendig. Endring i vaner, tankesett og bedriftskultur – det er vanskelig det! Forståelse er bare første trinnet – det som blir avgjørende er at ledelsen signaliserer tydelig at man faktisk ønsker endring.

    Du har sikkert rett i at veilederen ikke utelukker smidig, men du skal ha svært bevisste “ildsjeler” i prosjektledelsen for at de skal klare å gjennomføre ganske hyppige leveranser, utvikle scopet underveis og samtidig være “complient” med veiviseren. SPK hadde vel nettopp en slik sterk og bevisst prosjektledelse. Det foregår som du er inne på mye ganske smidig aktivitet i det offentlige, men det er fortsatt langt fra hovedregelen og de har ingen støtte i veilederen. Dessuten har de motstandere i anskaffelsesreglement og kontraktshåndtering.

    Vi er veldig enig i at prosjektet får for mye fokus, på bekostning av hele livssyklusen til produktet. Dette er sub-optimalt og fører lett til teknisk gjeld siden vi blir premiert for å *bli ferdig med prosjektet* hvilket går på bekostning av den langsiktige kvaliteten. Selvsagt gjør det det – prosjektet er en midlertidig organisasjon som ikke har ansvar for vedlikehold!

  17. Written by Lars Nokken
    on 03/03/2014 at 10:59 am
    Reply · Permalink

    Jeg har selv (i mine unge år) vært med på å gjøre programvareutvikling etter ”vannfallsmetoden”. Jeg tror det må være minst 20 år siden erkjennelsen av at dette ikke fungerte hensiktsmessig slo rot i stor bredde innen kompetansemiljøet. Programvareutvikling basert på at alt skal detaljspesifiseres først før noe kodes og testes har aldri fungert tilfredsstillende. Jeg kjenner ingen som er uenig i dette.
    Heldigvis har vi i løpet av disse årene kommet dit at det finnes programvare utviklingsmetodikk som fungerer vesentlig bedre. Opp gjennom årene har det florert en haug med ulike varianter av slike metoder under ulike navn og innpakninger. De siste årene er det et utvalg av ulike metoder, samlet under hatten Smidig utviklingsmetodikk, som er i skuddet. Jeg skal vokte meg vel for å bli oppfattet som å prøve å belære noen om Smidig. Det er prosjektstyring som er blitt mitt fag. Men utfra en del års erfaring fra prosjektledelse og prosjektkontor innen miljøer som har brukt Scrum med positiv erfaring, har jeg blant annet notert meg følgende:
    • Scrum er basert på mange og tidlige leveranser. Dermed skapes det grunnlag for tidlige tilbakemeldinger og eventuelle nye erkjennelser av de faktiske behovene og riktige prioriteringer.
    • Scrum er godt egnet til å håndtere detaljering og endringer i kravbildet underveis, og legger dermed til rette for at resultatet blir riktigere i forhold til det som oppdragsgiver egentlig trenger.
    • I forkant av hver sprint må oppdragsgiver/produkteier gjøre et aktivt valg av elementer i neste leveranse, forhåpentligvis prioritert i forhold til forretningsmål.
    I sum styrker selvsagt disse punktene nytteverdien av leveransene, og gir større gevinstrealisering. Det er jo det som er poenget med et prosjekt! For øvrig er det så vidt jeg har registrert en gjennomgående erfaring at metoden gir større effektivitet i utviklingsteamet og dermed kortere gjennomføringstid. Kanskje en effekt av den daglige tette kommunikasjonen og samhandlingen?

    Begrepet ”vannfallsmetode” er for meg direkte knyttet til programvareutvikling. Når dette begrepet brukes om Prosjektveiviseren blir det for meg noe fundamentalt som ikke stemmer. Prosjektveiviseren er ikke en metode for programvareutvikling. Det er den aldri ment å være og kommer heller aldri til å bli. Ingen har noen gang ment at den skal være egnet til å gjennomføre programvareutviklingen i et prosjekt. Til det bruket har vi som dere vet utmerkede metoder som er laget for dette formålet, og er godt egnet for dette.
    På den annen side, er modeller for programvareutvikling ikke laget for, og ikke egnet for, å ivareta behovet for overordnet prosjektstyring. Prosjektveiviserens hovedhensikt er å styrke forståelsen blant virksomhetsledere i offentlig sektor av deres helt sentrale rolle i forhold til virksomhetens bruk av prosjekter som virkemiddel for nå sine strategiske mål. Det vil si; starte flere riktige prosjekter. Derfor blir linjeorganisasjonens svært viktige, men ofte noe stemoderlig ivaretatte rolle i forkant av prosjektet «løftet opp» og synliggjort i konseptfasen. Her klarlegges det faktiske behovet, mulige eller forventede gevinster konkretiseres, og ulike konseptuelle måter å tilnærme seg dette på i et eventuelt prosjekt vurderes.
    På samme måte er linjeorganisasjonens ansvar og eierskap til realisering av gevinstene (som resultat av prosjektets resultater) synliggjort ved en linje-eid fase for gevinstrealisering til slutt. Hensikten med denne fasen er å påvirke til at gevinstrealiseringen ikke ”går i glemmeboken” etter at prosjektet er avsluttet, slik som så altfor ofte er tilfellet. Etter som ansvaret for den fasen ikke ligger i prosjektet er den logisk nok tegnet inn i oversiktsbildet etter prosjektets avslutning. Det betyr selvsagt ikke at alle gevinstrealiseringsaktiviteter skal legges til etter at prosjektet er avsluttet. For leveranser som er overlevert tidlig i prosjektet bør selvsagt gevinstrealiseringen iverksettes umiddelbart (i henhold til gevinstrealiseringsplanen) så sant det er mulig. Dette er faktisk også eksplisitt omtalt i Prosjektveiviseren. Men ja, dette poenget kunne med fordel ha vårt synliggjort mye bedre. Men så er det jo heldigvis slik da, at det er fullt tillatt å bruke hodet i tillegg til en prosjektmodell.
    I Prosjektveiviserens prosjektfaser (planleggingsfasen, gjennomføringsfaser og avslutningsfasen) er det primære fokuset satt på prosjekteierstyring og grenseflaten mellom prosjektleder og prosjekteier. Hensikten med planleggingsfasen er å klargjøre prosjektets mål, rammebetingelser, overordnet ansvar organisering, samt strategien for hvordan prosjektet overordnet skal styres. Denne planleggingen er ikke forutsatt å skulle gå ned på detaljert kravspesifikasjonsnivå fra A til Å. Detaljnivået her bestemmes av oppdragsgiver, og er avhengig av tillitsforhold og organisasjonsmessig relasjon mellom oppdragsgiver/prosjekteier og leverandør/prosjekt. Enten det dreier seg om en ekstern oppdragsgiver med en formell avtale eller en intern oppdragsgiver hvor et styringsdokument utgjør ”prosjektkontrakten” er det detaljnivået i denne som setter eventuelle begrensninger for handlingsrommet for bruk av smidig utviklingsmetodikk, og ikke Prosjektveiviseren. I denne sammenheng kan det være greit å huske at det viktige og grunnleggende Prince2-prinsippet om at bruken av modellen alltid skal tilpasses til prosjektets type, omgivelser, størrelse etc også gjelder for Prosjektveiviseren.
    Selv om Gjennomføring er tegnet som én boks i oversiktsbildet, står det klart beskrevet i teksten at den både kan og bør splittes i delfaser. Uavhengig av type prosjekt og hva prosjektet skal levere kan det det være mange gode grunner for dette. I et prosjekt som inneholder programvareutvikling basert på Smidig blir knytningen veldig åpenbar. Prosjektveiviserens beslutningspunkter i forkant av hver delfase sikrer da involveringen og den bevisste prioriteringen fra oppdragsgiver/prosjekteier/ styringsgruppe og bidrar dermed til å knytte prosjektmodellen og utviklingsmetoden sammen.
    Prosjektveiviseren er laget med tanke på relativt store prosjekter i offentlig sektor. Slike prosjekter har ofte flere typer leveranser involvert. Det kan være et element av programvareutvikling, det kan være anskaffelser av ulike slag, det kan være endringer av virksomhetsprosesser og kanskje organisasjonsendringer knyttet til disse, osv. Egentlig finnes det ikke programvare utviklingsprosjekter eller anskaffelsesprosjekter. Derimot finnes det PROSJEKTER hvor for eksempel programvareutvikling og anskaffelse er involvert som to måter å fremskaffe de leveransene som prosjektet har ansvaret for. Disse to krever selvsagt ulike arbeidsprosesser og metoder. Hvis vi ser for oss disse organisert som delprosjekter blir strukturen ganske innlysende. Delprosjektene og delprosjektlederne vil primært forholde seg til henholdsvis en metode for programvareutvikling og en anskaffelsesprosess, mens hovedprosjektlederen vil primært forholde seg til Prosjektveiviseren. Selvsagt må hovedplanen og delprosjektplanene henge sammen, og det blir prosjektlederteamets viktige oppgave. Poenget mitt er at en prosjektstyringsmodell og en utviklingsmetode er helt forskjellige ting, men som må ses i sammenheng og brukes parallelt til det de er laget for. Hvorfor ikke løfte blikket (slik jeg oppfatter at Cristian i en stor grad gjør) og ta inn over seg at verden er litt større enn akkurat den delen jeg selv lever i og ser som verdens midtpunkt? Kanskje det finnes andre like viktige innfalsvinkler og interesser sett fra et annet ståsted, posisjon og profesjon?
    Prosjektveiviseren er ikke perfekt. Det er rom for forbedringer. Difi tar gjerne imot konstruktive forslag og innspill til forbedringer som kan bidra til flere riktige prosjekter som blir gjennomført riktig.
    Jeg håper jeg med dette innlegget har fått frem at Prosjektveiviseren også egner seg brukt i kombinasjon med smidig metodikk. Om og hvordan dette bør gjøres i det enkelte prosjekt må være opp til hver enkelt virksomhet å bestemme, bl.a. ut fra prosjektets egenart og organisasjonens modenhet.

  18. Written by gamsjo
    on 03/03/2014 at 12:08 pm
    Reply · Permalink

    Hei Lars,
    takk for utfyllende svar!

    Du ser opplagt verden gjennom Prosjektlederens briller (se http://scrummaster.no/2014/sannheter-halvsannheter-og-prosjektstyring/), og du har opplagt mye erfaring. Jeg har heller aldri møtt erfarne prosjektledere som varmt omfavner ren vannfallsmodell for programvareutvikling. Allikevel er det slik adferd vi stadig vekk ser! Hva kan det komme av?

    Du skriver: “ingen har noen gang ment at den (Prosjektveiviseren) skal være egnet til å gjennomføre programvareutviklingen i et prosjekt. Til det bruket har vi som dere vet utmerkede metoder som er laget for dette formålet, og er godt egnet for dette.” Hva kommer det da av at seminaret den 18 desember overhodet ikke inneholder “smidig-retorikk” (lære mens man jobber, engasjerte, selvstyrte team, tett brukersamarbeid, løpende verdiskapning, ikke låse seg for tidlig etc) men bare “vannfallsretorikk” (grundig forarbeide, solide planer, god prosjektstyring etc..)? Er det fordi digitaliseringen av norsk forvaltning skal foregå med en neglisjerbar mengde programvareutviklig? Jeg forstår at prosjekter ofte inneholder annet enn programvareutvikling, men kjøper på ingen måte at dette utgjør en liten andel. Men som jeg har gjentatt til det kjedsommelige: Bruk gjerne prosjektveiviseren til prosjekter som har lite nyutvikling og innovasjon.

    Vannfallsmodellen er egentlig ikke hovedproblemet, men den blir ofte brukt som symbol på “alt som er galt”. Da blir ting lett litt unyansert og tabloid. Jeg innrømmer det. Så hva er da hovedproblemet – som smidig løser? Jeg tror det er bedre å da trekke fra Taylors “Scientific Management” – det arbeiderne bare utfører og trenger i liten grad “tenke sjæl”, mens lederne ovevrvåker, kontrollerer og forbedrer.

    Agile Manifesto var ikke i utgangspunktet et oppgjør med vannfallsmodellen, men snarere med “gjeldende tankesett”. Det Agile community (innbefatter de fleste av de 17 som lagde manifestet i 2001 og som er aktive forfattere, bloggere og er å treffe på agile-seminarer) fokuserer på er *andre ting enn prosjektstyring*. Prosjektet – og prosjektstyring får en alt for dominerende plass.

    Manifestet med mine ord:

    1. Det som vil gi suksess er at du har dedikerte, motiverte, erfarne utviklere som kommuniserer godt med hverandre og med brukerne. IKKE prosedyrer eller prosjektstyringssystemer!

    2. Det som vil gi suksess er at du klarer å levere noe ferdig funksjonaliett så tidlig som mulig og så ofte som mulig. Og så *billig* som mulig.

    3. Det som vil gi suksess er at kunde og leverandør er i samme båt, har tillit til hverandre ogjobber tett sammen hele tiden. Dette er krevende kontraktsmessig, men heldigvis fungerer Time/Material helt fint.

    4. Det som vil gi suksess er at du ikke låser planen før du er nødt, at du ser på endringer som verdi, og at du er forberedt på å feile fra tid til annen.

    Prosjektledere har en tendens til å “glemme” den første setningen og stort sett snakker de bare om nummer 2 og 4.

    Du skriver “På den annen side, er modeller for programvareutvikling ikke laget for, og ikke egnet for, å ivareta behovet for overordnet prosjektstyring”. Her er jeg helt uenig – gode smidige utviklingsløp skaper en gjennomsiktighet som kan gi svært gode styringsmuligheter (se f.eks her: http://scrummaster.no/2014/kunsten-a-planlegge-det-ukjente/).

    Smidig er et annet paradigme enn tradisjonell styring og ledelse. Det må solid endring til. Hvis Difi ønsker å få tatt ut det store potensialet som ligger her , må de begynne å signalisere *endring* – ikke *fortsett som før*.

    Og for orden skyld, igjen: Behold gjerne prosjektveiledere som den er og la den leve sitt liv, bare sørg for at det finnes et helhjertet, smidig alternativ for de initiativene med usikkerhet, innovasjon og dynamikk. Denne *må* se annerledes ut – også på høyeste nivå. Man må signalisere at dette er noe annet, hvis ikke får vi den sedvanlige “same shit – new wrapping”.

  19. Written by Niklas Bjørnerstedt
    on 03/03/2014 at 8:24 pm
    Reply · Permalink

    Her var det mye ønsketenking synes jeg. “If it walks like a duck, quacks like a duck and looks like a duck: it probably is a duck.” I følge difi selv: “Prosjektveiviseren er en modell for overordnet prosjektstyring”. Den beskriver seks steg med beslutspunkter mellom hvert steg. Det er så lineært det kan bli. Så klatter man på litt smidig og tror at det hele blir moderne…

    Her er et konstruktivt forslag: For noen år siden leste jeg og blogget (http://www.leanway.no/standardized-work-versus-checklists/) om en spennende bok: The checklist manifesto.
    Hvis difi har en reell ønske om å åpne for moderne tilnærminger samtidig som man ønsker å gi konkret hjelp til prosjektstyring så er sjekklister mye bedre enn et lineært flytdiagram. Sjekklister spesifiserer ikke rekkefølgen på ting, den beskriver det du ikke må glemme. Da åpner man for mer enn inkrementell utvikling som dessverre mange blander sammen med smidig.

  20. Written by Eirik Andersen
    on 11/03/2014 at 2:37 pm
    Reply · Permalink

    Hei Geir også her. Takk for at du drar i gang debatt. Jeg ser Lars hos oss har engasjert seg i kommentarfeltet, og vi har lag ut to innlegg på Difi-bloggen http://blogg.difi.no/
    Eirik

    Eirik Andersen
    Kommunikasjonsdirektør i Difi

    • Written by gamsjo
      on 11/03/2014 at 3:57 pm
      Reply · Permalink

      Hei Eirik,
      jeg har svart på Difi-bloggen. I påvente av moderator legger jeg også svaret her:
      ————–
      Hei Ellen,
      først en misforståelse som tydeligvis er seiglivet: Vi kritiserer prosjektveiviseren til bruk for *programvareutvikling*, og vi fikk til og med inn en setning om dette på den svært begrensede plassen i kronikken: “Dette kan fungere godt for en del typer prosjekter, men er særdeles lite egnet for kunnskapsintensivt, dynamisk og innovativt arbeid som programvareutvikling vitterlig er.”

      OK, du bekrefter her igjen at DIFI og det man kan kalle “smidig-miljøet” ser helt forskjellig på hva som ligger i Smidig systemutvikling. Dette er definert i agilemanifesto.org og jeg har fulgt mange av disse opphavsmennene tett i de siste 10 årene og jeg vet hva de legger i dette; Agile er *noe helt annet* enn vanlig prosjektstyring. Det er på en måte et annet paradigme. Det skal mao en grunnleggende endring til. Difi skriver mye bra om endringsledelse i den rapporten du refererer til. Om dere vil påvirke endring i retning av smidig, nytter det ikke å bare si at “det går an å kjøre smidig med prosjektveiviseren”. Det er naivt.

      Jeg er egentig ikke så opptatt av prosjektveiviseren, den har på en måte blitt et symbol på “gammeldags tankegang” som fører til store, usikre, dyre og feilslåtte prosjekter. La gjerne prosjektveiviseren ligge der. Men om Difi vil bidra til en vesentlig endring slik at digitaliseringsprosjektene blir billigere, tryggere, raskere og treffer brukernes behov bedre, så må det finnes et helhjertet, troverdig smidig alternativ. Denne må signalisere tydelig, på øverste nivå, at dette er annerledes. Den kan godt eksplisitt addressere ren programvareutvikling – i starten.

      Det er fint med debatt i slike fora, men det spørs hvor lenge det er formålstjenelig å fortsette å snakke forbi hverandre på denne måten. Jeg gjentar meg selv hele tiden, føler jeg. Skal vi komme videre tror jeg Difi og “smidig-miljøet” må møtes, noe jeg har tatt initiativ til mange ganger.

Subscribe to comments via RSS

Leave a Reply