altinn – som forventet

Det fine med kriser er at det gir en anledning til å lære. Enkelte områder ansees så kritiske at det øyeblikkelig nedsettes en havarikommisjon eller lignende når en ulykke inntreffer. Hensikten er selvfølgelig å dra lærdom av hendelsen. Det positive med de siste dagers altinn-problemer er at DNV sin Tekniske Rapport Vurdering av Altinn II Plattformen ble frigitt. Rapporten har faktisk en litt misvisende tittel, for her vurderes i stor grad utviklingsprosjektet og ikke den ferdige løsningen. Veldig interessant lesning!

Prosjektets utilstrekkelighet


Altinn II utviklingen ble kjørt som et tradisjonelt prosjekt mot en sluttermin, med Accenture som leverandør. Dette prosjektet må kunnes sees på som ganske vellykket, for Altinn er blitt et system som gjør hverdagen til både bedrifter og enkeltpersoner betydelig enklere. Men så var det dette med kvaliteten da. Hvor gode betingelser har vi for å levere god kvalitet når arbeidet organiseres som prosjekter? SMÅ! I hvert fall om det som skal utvikles er komplekse systemer. Vi har snakket og skrevet om dette gjentatte ganger.

Problemet er altså at det synes uungåelig at vi styrer mot tid og kost, i stedet for å fokusere på høy kvalitet. For hva er egentlig høy kvalitet i programvare? Ikke helt lett for en stakkars kunde å vite hvordan man måler dette. Og det som ikke er målbart, blir konsekvent ofret – når vi er under press. Leverandøren har som regel kunnskap om hva som er kvalitetsmessig godt håndtverk, men velger under press å ofre dette. For godt håndtverk tar tid.

Testing og feilretting

“Alle” i programvarebransjen vet nå ta du må teste grundig, automatisk og så tidlig som mulig. Feil skal ikke finnes i produksjon – da er de ekstremt dyre å finne og rette. Vi automatiserer gjerne tester på flere nivåer. Problemet med dette er at det tar tid. Fra rapporten:

5.2 Feil og feilretting

Som beskrevet i avsnitt 5.3 Test, er det vår oppfatning at kvaliteten på testingen har vært for dårlig i alle faser – fra modul-/ enhetstest til akseptansetest. En konsekvens har bl.a. vært at det er produksjonssatt en løsning med mange kjente og ukjente feil. For dårlig testing i alle faser har resultert i at mange feil har blitt oppdaget sent. Feil som burde vært funnet

i modul-/ enhetstest avdekkes ikke før i integrasjonstest, feil som burde vært funnet i integrasjonstest avdekkes ikke før i systemtest, osv. Erfaringene fra akseptansetest er at det ble funnet feil som klart burde vært avdekket tidligere. Videre har vi også fått opplyst at fatale feil ikke ble avdekket før produksjonssetting.

Grafen er sakset fra rapporten og viser DNV sitt syn på kostnadskonsekvensene ved å oppdage feil sent i prosessen.

Dette viser en utvikling som ikke akkurat er under kontroll. Når man finner så mye feil så sent i prosessen forteller det oss at dette systemet ikke er stabilt.

Teknisk Gjeld

Rapporten peker gjentatte ganger på at man her har bygget opp en teknisk gjeld. Teknisk gjeld er en god metafor for det som skjer når man forsøker å vinne tid eller penger ved å unnlate å gjøre håndtverket skikkelig. Testing er en opplagt kandidat til å gjøre mindre av. Dokumentasjon og refaktorisering av kode og struktur er andre områder. DNV har skutt inn et utdrag fra en annen rapport:

CapGemini gjorde på oppdrag av BRREG to kodegjennomganger en i 2009 /112/ og en i 2010 /113/.
Fra CapGemini code review report /112 / har vi sakset følgende oppsummering:
“De svakeste områdene i Altinn II er følgende:
Enhetstestene inneholder mange feil og er ikke komplette
Deler av koden virker uferdig med mange TODO‟s og utkommentert kode
En del metoder er svært lange og komplekse
Noen steder har vi funnet try-catch-blokker som ”svelger” feil uten å gjøre noe med disse
Presentasjonsprosjektet framstår som rotete. Det er ingen skiller mellom presentasjon,
datahåndtering og forretningslogikk. “

Endringskostnader

CoC - Cost of Change

CoC - Cost of Change

Alt dette peker mot det vi ofte kaller “slutterminens forbannelse”. Når man kjører komplekse prosjekter på denne måten virker det som en naturlov at denne gjelden blir stor. Stor teknisk gjeld fører til ustabile systemer med mye feil. Men det har også en annen effekt, nemlig at endringskostnadene over tid skyter i været.

IT-systemer har ofte (overraskende) lang levetid, og de er under stadig utvikling. Det er sjelden slik at en stor leveranse er slutten på nyutvikling. Når vi så kjører mot slutterminen med en leverandør som er på fastpriskontrakt får vi også unødvendig dyrt vedlikehold over tid. De store IT-kundene bør tenke nøye igjennom hvordan de bruker pengene på IT-utvikling. Kanskje det er på tide å utfordre prosjekttankegangen?

Bruk rammeavtale i stedet!

Altinn er ikke enestående, dette er normalen innen IT-prosjekter i norge. Vi kan anta at det er bygget opp en formidabel teknisk gjeld i IT-systemene her i landet. Men det er fullt mulig for en IT-kunde å ta styringen selv. I stedet for å legge ut fastprisavtaler med en leverandør som ikke har egen interesse av å levere høy kvalitet kan man bruke en “Time and material” type avtale der leverandørene stiller opp med kompetanse og ressurser, mens kunden selv styrer. Vi tror dette vil kunne spare samfunnet for mye tid, penger og ergrelser. I en rammeavtale kan fokuset ligge på det som er viktig over tid. Man kan spare mye ressurser i startfasen, siden man slipper den store, tunge anbudskonkurransen. Samtidig kan styringen gjøres betydelig enklere gjennom smidige metoder. Og man får validert løsningene underveis og kan med enkle grep unngå at testing og annen god praksis ofres til fordel for framdrift.

Begynn å ta virkeligheten på alvor! 

 

Posted on March 22, 2012 at 9:56 pm by gamsjo · Permalink
In: prosjektledelse, Samfunn · Tagged with: , ,

21 Responses

Subscribe to comments via RSS

  1. Written by Arve Systad
    on 23/03/2012 at 12:10 am
    Reply · Permalink

    Bra skrevet. Selv synes jeg det er synd at det blir spart penger på slike løsninger – enten det er kunde eller leverandør sin skyld. Slike systemer vil spare samfunnet for milliarder av kroner på sikt, så om altinn hadde kostet det dobbelte hadde samfunnet allikevel spart mye på det over systemets levetid. Og tenk hva det kunne/burde ha gjort med kvaliteten.

    • Written by gamsjo
      on 23/03/2012 at 7:38 am
      Reply · Permalink

      Jeg tror du kan ha rett i det, Arve. Hadde de rene utviklingskostnadene blitt doblet, kunne livstidskosten antageligvis kunne blitt lavere! Dessuten kunne man med mer smidig gjennomføring nok truffet brukernes behov bedre.

  2. Written by Pål Eie
    on 23/03/2012 at 9:28 am
    Reply · Permalink

    Veldig bra innlegg!
    Men det er en siden av denne diskusjonen som vi ofte glemmer, og det er at vi er veldig raske med å skylde på kunder som gir for lite penger eller for dårlig tid!

    Alt for mange ganger har jeg sett at en veldig stor del av problemet skyldes mangel på helhetstenkin og kvalitetsfokus hos utvikelere og arkitekter. Etter min mening er også følgende faktorer ofte bakenforliggende:

    * For mye “leking” med ny teknologi, spesielt i prosjekter som går over flere år blir dette et problem da det stadig sys inn nye teknologier som arkitekter og utviklere har lyst til å prøve

    * Liten kompetanse hos utviklere på prinsipper som clean code, patterns og gode tredjepars rammeverk

    * Mangel på oppdatert teknisk kompetanse hos utviklere og arkitekter (!). De meste av problemer lar seg løse på et vis med gammel og lite IT-kunnskap, men resultatet blir da at vedlikeholdskostnadene blir høye, løsningene tåler dårlig endringer over tid, og koden blir ustabil og skalerer dårlig

    Det hjelper fint lite å pøse på med mye mer penger for å løse disse problemene! Med dyktige utviklere og arkitekter er det helt klart mye å hente mht. teknisk gjeld og kvalitet, men i mange tilfeller hjelper det fint lite å øke budsjetter og tidsrammer hvis det ikke samtidig settes fokus på kvaliteten hos utviklere og arkitekter.

    Dersom en klarer å gjøre noe med begge deler, og som du sier våger å satse med på “time and material” er det virkelig store potensialer å hente!

    • Written by gamsjo
      on 23/03/2012 at 5:16 pm
      Reply · Permalink

      Takk Pål!
      Jeg er enig i mye av det du sier – kunden og leverandøren må begge ta ansvar for helheten. Jeg tror utviklere og arkitekter som får møte brukerne og som tar eierskap til de verdiene de skal skape vil gjøre sitt beste for å gjøre en god jobb. Også for å interessere seg for nyere prinsipper som Clean Code o.l.

  3. Written by Per Spilling
    on 23/03/2012 at 10:12 am
    Reply · Permalink

    Helt enig med det du skriver Geir. Prosjekter som dette burde aldri gjennomføres som fastprisprosjekter. Jeg ville ha anbefalt følgende for et prosjekt som dette:

    1. Sett sammen et *lite* team (maks 10 personer) med egne folk pluss med de beste utviklerne/arkitektene man kan finne fra forskjellige konsulentfirmaer. Behold prosjektstyringen selv

    2. Lag sentrale deler av arkitekturen som “tracer bullets”, og verifisér at den valgte arkitekturen oppfyller krav til sikkerhet, robusthet, skalerbarhet, testbarhet og “automatiserbarhet”. For et system som skal være så skalerbart og robust som Altinn så bør man se på hvordan de har fått dette til hos Amazon, Facebook osv.

    3. Gitt at (2) er ok; Etabler en modularisering som gjør at moduler i arkitekturen kan utvikles hver for seg, og produksjonsettes hver for seg. Moduler designes som autonome applikasjoner/tjenester som er mest mulig uavhengige av andre moduler. Asynkron kommunikasjon (meldingskø) brukes for utveksling av data mellom moduler.

    4. Etabler standarder for design, utvikling og dokumentasjon av grensesnitt mellom moduler. Gjøres med vilje ikke før man er kommet et stykke ut i prosjektet for å unngå Big Design Up Front.

    5. Når alt dette er på plass, med automatisert testing og automatiserte prosesser for produksjonssetting av moduler, da kan man begynne å etablere flere team som får ansvar for hver sin modul.

    Et spennende offentlig prosjekt som gjennomføres på en slik måte, og i tillegg legger ut sin egen kode som open source, er GOV.UK: http://blogs.ft.com/tech-blog/2012/02/beta-gov-uk/#axzz1pvfHN26X

    • Written by gamsjo
      on 23/03/2012 at 5:22 pm
      Reply · Permalink

      Hei Per,
      jeg er veldig enig i fremgangsmåten (i store satsninger) med å sette i gang et håndplukket team i starten og kjøre noen iterasjoner der man fokuserer på arkitekturavklaringer, utviklingsmiljø og standarder. I denne fasen kan man godt utvikle noe funksjonalitet, for å få validert løsningen. Dette kan man se på som en slags analysefase og vil sannsynligvis gi mye mer verdi enn en tradisjonell analyse. På samme tidsbruken. (Dette er for øvrig akkurat det vi underviser i Scrum kursene).
      Takk for linken til Gov.uk – skal få sett på dette senere.

  4. Written by Per Spilling
    on 23/03/2012 at 10:37 am
    Reply · Permalink

    Med en rammeavtale og en “smidig” fremgangsmåte slik som skissert så er jeg forøvrig temmelig sikker på at utviklingskostnadene hadde blitt lavere enn de har blitt med fastprismodellen som man har valgt. Særlig nå som vi ser at man sannsynligvis må lage systemet på nytt fra bunnen av.

    • Written by gamsjo
      on 23/03/2012 at 5:36 pm
      Reply · Permalink

      Ja, rammeavtale kan gjøres mye mindre byråkratisk og ressurskrevende. Jeg har sett en del offentlige prosjekter i det siste – som bruker “Scrum” og hevder å være smidig – og som bruker ufattelig mange mennesker i ulike roller for å følge opp leverandøren. Dette er “waste”. Bruker man for eksempel Scrum fornuftig vil man kunne bruke gjennomsiktigheten dette gir i stedet for å sette folk i oppfølgings- og koordineringsroller.

  5. Written by Thorbjørn Sigberg
    on 23/03/2012 at 10:48 am
    Reply · Permalink

    Interessant artikkel! Det er også en kontinuerlig utfordring for de som leder tradisjonelle prosjekter å holde kontroll over kvaliteten. Etterhvert som oppgavene tårner seg opp og tiden blir knappere, vil en utvikler kutte hjørner og produsere dårligere kvalitet uansett hva prosjektledelsen sier.

    • Written by gamsjo
      on 23/03/2012 at 5:25 pm
      Reply · Permalink

      Takk Thorbjørn. Ja det synes å være en naturlov at når man fornemmer presset så vil man kutte hjørner. Jeg har gjort dette selv i min tid som programmerer, og jeg synes ikke man skal anklage utviklere for å ha lav yrkesstolthet eller slikt. Dette er menneskelig og lar seg lett forklare med systemtenkning.

  6. Written by Sten Johnsen
    on 23/03/2012 at 11:03 am
    Reply · Permalink

    Kjempebra og veldig to-the-point for å si det på ny-norsk. Jeg berører samme tema i en av mine siste blogg-artikler på http://blogg.bouvet.no/2012/03/09/the-vicious-release-circle/ selv om den i hovedsak handler om det å utsette alt i store big-bang releaser, henger det sammen i hvor feilene og kostnadene med feilene oppstår.
    En smidig tilnærming hadde sansynligvis tydeliggjort mange av problemene på et mye tidligere stadium.

    • Written by gamsjo
      on 23/03/2012 at 5:32 pm
      Reply · Permalink

      Hei Sten!
      God artikkel! Enig i at hyppigere releaser og smidig tilnærming er nøkkelen til veldig mye av det vi sliter med innen IT-utvikling. Men det vil ofte være reelle begrensninger på hvor ofte man kan release. Ikke alle er som Amazone eller FINN.no…

  7. Written by Hans Erland Ringsvold
    on 23/03/2012 at 12:18 pm
    Reply · Permalink

    Hei Geir

    Interessant vinkling og som vanlig kloke synspunkter på en kompleks problemstilling…. Om du har rett medisin til pasienten er jeg noe mer usikker på…

    Det er en grunn til at mange selskaper vegrer seg for T&M-kontrakter og det tror jeg i stor grad handler om manglende evne til å etablere partnerskap (på begge sider av bordet), tillitt (ref. år 2000, konsulenter som skor seg, senior i første møte – en gjeng juniorer når arbeidet starter etc.) og mange grådige konsulenter…

    Da blir det litt catch 22 at selskaper velger fastpriskontrakter e.l. (lov om offentlig anskaffelse er vel en katalysator for dette også..) som inneholder en mengde skjulte (kvalitet, teknisk gjeld etc) og ikke skjulte kostnader (risikomargin på estimat – flåsete kalt bullshitfaktoren). Man velger en dårlig og dyrere modell fordi alternativet anses, om mulig, som dårligere (ref over).

    At man ikke lykkes i større grad med partner modeller type risk-sharing, målpris etc. handler kanskje om modenhet i markedet? Kanskje disse modellene er en bedre medisin for pasienten og som en gylden middelvei mellom fastpris og t&m?

    Jeg ser også med glede at Agile metoder og scrum får større utbredelse og oppmerksomhet men dette er i større grad i “software hus” og blant utviklerskaren (min opplevelse)… Jeg kunne ønske noen (i større grad) klarte å sette dette på agendaen (til ledelsen) i større bedrifter som ikke nødvendigvis lever av softwareutviklig men hvor prosjektledelse med grad av PMI/Prince2 som gjennomføringsmetodikk er det gjeldene for alle typer IT-relaterte prosjekter..

    Skal man få til dette må agil/scrum-community klare å sette styringsprosesser i en bedre sammenheng for gjennomføringsmetodikken da det er dette tradisjonell prosjektledelse blir verdsatt for (les: metode for å balansere og forplikte seg/noen til alle 4 aksene i modellen din). Min påstand..

    Gjennomføringsmetode/prosesser, kontraktsformer, partnermodeller etc er gjensidig avhengige av hverandre og for å løse det ene må vi nok endre på flere områder…..

    • Written by admin
      on 24/03/2012 at 8:32 am
      Reply · Permalink

      Takk for god kommentar Hans!
      Enig i at T&M-modellen ikke nødvendigvis vil løse alle problemer. Her det selvsagt også mye som skal fungere. Jeg tror en viktig suksessfaktor ligger i at man sikrer seg langsiktige avtaler med team-deltagerne. Da blir det mindre viktig hvor de i realiteten er ansatt. Suksess i systemutvikling er mye mer avhengig av motiverte, kompetente teamdeltagere enn all verdens prosjektledelse. Min påstand:-)

      Vi i smidig-miljøet har utvilsomt en kommunikasjonsutfordring – kunne du forklare litt mer inngående hvilke styringsprosesser o.l. som vi bør kommunisere bedre?

  8. Written by Håkon Amundsen
    on 23/03/2012 at 1:32 pm
    Reply · Permalink

    Elefanten i rommet er etter min mening: Lønn. Det er et paradoks at staten gang på gang kan bruke enorme summer på å anskaffe nye IT-systemer, men ikke til å gi konkurransedyktig lønn til å ansette egne folk med tilstrekkelig kompetanse til å lede utviklingen.

    • Written by admin
      on 24/03/2012 at 8:34 am
      Reply · Permalink

      Hei Håkon,
      jeg er enig i at offentlig sektor i noe større grad bør utvikle systemene med egne ansatte – og da må de selvsagt tilby ok lønn.

  9. Written by Terje
    on 27/03/2012 at 3:49 pm
    Reply · Permalink

    Igjen en flott artikkel som tar for seg mange problematiske aspekter ved dagens begrensede prosjekttankegang, og det er utvilsomt mange flere som kunne hatt nytte av større bruk av SCRUM eller annen “agil” tankegang.

    Men jeg vil likevel ikke avfeie et tidsbegrenset prosjekt som arbeidsform helt i alle sammenhenger, det kommer helt an på i hva som skal utivkles og hvilke krav man har til sikkerhet, brukervennlighet og skalerbarhet. Begrunnelsen er at kunden ikke nødvendigvis har hverken kompetanse eller ressurser til å ta stå for rollen som prosjektleder der det vil være uforholdsmessig dyrt å skaffe slik kompetanse for prosjekter med begrenset kompleksitet.

    Ansvaret er heller ikke bare kundens som Pål over her påpeker, i tillegg til det han nevner så finnes det desverre også mange tilfeller av mer eller mindre bevisste “underslag” i forhold til å presse kostnader for å vinne anbudsrunder, og det er altfor ofte dette som er den egentlige grunnen til at det leveres for dårlig kvalitet og/eller at tidsfrister overskrides. Dette er også et problem som ikke bare rammer kunden, men også den enkelte leverandør og mulig bransjen som helhet i form av manglende kredibilitet på sikt.

    Videre bør også kunde og leverandør bli flinkere på kommunikasjon når det gjelder prioriteringer og hva som er mulig å forvente innen de avtalte rammene. Dette gjelder da spesielt fastprisprosjekter, men også “løsere” rammeavtaler (T&M) som har et lengere tidsperspektiv, for det er strengt tatt ikke alt som bør prioriteres for enhver pris. Et eksempel kan da være altinn. Har kunden (altså staten) egentlig noe godt rasjonale for hvorfor man ønsker å skalere det “helt opp” slik at samtlige hoder i Norge kan sjekke baksmellen sin på en og samme tid? Er dette så viktig sett i lys av altinns helhet? Hadde det for eksempel vært mer fornuftig å dele inn landet i geografiske regioner slik at man ikke må bruke mye ressurser på en skalering man ikke behøver resten av året?

    Min påstand er rett og slett at man ikke er redelig nok i forhold til de faktiske behovene. I altinns tilfelle kunne man tenkt seg at man heller bruker noen av de store ressursene på skalerbarhet på sikkerhet i stedet ref. diverse artikler om privatpersoner som har fått opp en annens profil etter innlogging. Jeg etterspør vel rett og slett en større ærlighet under behovsprøving både fra både kunde og leverandør, og håper jeg får oppleve dette før “pigs fly” 😉

    Ellers er jeg ikke nødvendigvis alltid enig i at det ikke er behov for koordineringsroller. Kommunikasjonsbehovet og hvilke ressurser som skal allokeres må sees i sammenheng med hvilken utviklingsfase man er i, størrelsesorden (som ikke alltid er det samme som kompleksitet) og øvrige rammer under utvikling. Raske (men ofte viktige), tekniske og spesialiserte avklaringer tas ofte best av utvikleren selv eller noen som jobber tett mot vedkommende, og da gjerne mellom utviklere eller folk med sammenlignbar kompetanse. Eller det kan -som du påpeker- dekkes tilstrekkelig med gjennomsiktigheten man har i SCRUM.

    Større og mer komplekse avklaringer, diskusjoner eller rapporteringsprosesser tar i mange tilfeller mye av utviklerens tid og man kommer reelt sett før eller siden til et skjæringspunkt der det lønner seg å dedikere kommunikasjon til en koordinatorrolle. Dessuten er god koordinering/kommunikasjon heller ikke nødvendigvis en styrke hos alle utviklere. Misforståelser og forsinkelser kan gjerne unngås med koordinatorer som har en viss teknisk forståelse og gode kommunikative evner – Å stille de riktige spørsmålene til de riktige menneskene kan være fantastisk ressursbesparende!

  10. Written by gamsjo
    on 27/03/2012 at 8:01 pm
    Reply · Permalink

    Hei Terje,
    takk for en god, utfyllende kommentar!

    Jeg vet jeg er bastant og litt spissformulert i posten – og jeg er enig med deg i at det er tilfeller der man med fordel kan definere en leveranse på en termin. Når man skal utvikle noe stort og komplekst fra scratch vil man man naturlig nok måtte jobbe en stund før noe synlig funksjonalitet materialiserer seg på overflaten. Men jeg mener bestemt man bør etterstrebe å minimalisere dette så langt det er mulig. Argumentet om at krav til sikkerhet, brukervennlighet og skalerbarhet har noe å bety kjøper jeg ikke. At kunden i dag ikke har kompetanse til selv å kjøre smidig utvikling har du helt rett i, men dette kan man adressere gradvis.

    Om noen ikke er “rederlige nok” så tror jeg dette kan forklares med at man er to parter med litt ulike interesser. Man er seg selv nærmest…

    Koordineringsroller slipper vi ikke helt unna i de store utviiklingsoppdragene. Men jeg mener man har alt for lett for å tilordne en rolle så fort det er behov for å se noe på tvers. Dette er veldig ofte unødvendig, og man kan i stedet satse på selvorganiserende team med sterkt eierskap til sluttresultatet.

    Og så er det stadig et spørsmål om det er lurt å klumpe sammen så store prosjekter i det hele tatt. Ofte ville det vært mulig å isolere mindre utviklingsoppdrag for å slippe den virkelig store kompleksiteten.

  11. Written by Terje
    on 30/03/2012 at 11:39 am
    Reply · Permalink

    Hei igjen,

    Takker også for en god kommentar.

    Jeg er for så vidt enig at man i mange tilfeller kan redusere antall prosjekter med endelig sluttermin – dette bør da gjelder større og evt. komplekse prosjekter med et lengere tidsperspektiv, gjerne over et år. Dette fordi estimatene på slike “store” prosjekter har en tendens til å være unøyaktige eller rett og slett temmelig urealistiske og man har jo lest en fair share om prosjekter som har gått over termin med god margin eller som rett og slett aldri har kommet i mål.

    Men det er også en hake og det er at porteføljen av “SCRUM prosjekter” uten en endelig sluttermin har en tendens til å vokse og man kan risikere å “brenne inne” med en lang tråd med forskjellige prosjekter som på sikt kan bli tungt å håndtere både med tanke på ressurssallokering og det rent administrative rundt. Det bør i så fall settes en reell øvre grense for hvor mange prosjekter organisasjonen eller bedriften mener det er hensiktsmessig å håndtere i et og samme tidsrom. Eventuelt bør en vurdere å kombinere metodikker (dersom en har kompetanse til det!) og la mindre og mer oversiktlige prosjekter følge en mer tradisjonell metodikk og heller la de større prosjektene følge SCRUM orienterte prosesser.

    Ovenstående henger da sterkt sammen med organisasjonens modenhet og dette jeg skrev om “krav til sikkerhet, brukervennlighet og skalerbarhet” – som jeg muligens burde omformulert noe. Essensen er at en selvsagt kan benytte SCRUM som metodikk der kunde står som prosjektleder – men ikke før man som organisasjon er klar for det, og man bør i hvert fall ikke ta sikte på å gjennomføre store, kritiske prosjekter som sitt første SCRUM prosjekt. Selv om det er et “lettvekts” rammeverk, så bør en likefullt gi seg litt handlerom for å bli litt varm i trøya.

    Ellers er jeg enig i at man ikke bør tilordne koordineringsroller ved oppstart før man har klarlagt omfanget og koordineringsbehov. Dette bør heller skje gradvis dersom og når behovet for større mengder koordinering og/eller fagspesifikk kunnskap behøves. Samtidig ser jeg også at en slik policy kan være problematisk for mange, for det er ved prosjektstart man gjerne tilordner roller og det kan være vanskelig å tildele koordinatorroller senere i prosjektet.

  12. Written by Joachim Haagen Skeie
    on 16/04/2012 at 11:06 am
    Reply · Permalink

    Metodikk til side. Staten har betalt over 1000 millioner kroner for denne løsningen, hvor leverandøren, Accenture, sitter igjen med over halvparten. Om utviklingsmetodikken er det ene eller det andre unnskylder ikke i hverken tilbyder eller leverandør en løsning som ikke skalerer tilstrekkelig og som inneholder godt med feil.

    DNV har klart å måle antall kjente feil i løpet av utviklingsprosjektet, som betyr at både leverandør og tilbyder har mer eller mindre direkte tilgang til denne informasjonen også.

    At man ikke kan levere kvalitet i et stort fossefallsprosjekt tror jeg er en falitterklæring – Selvsagt kan man det! At forholene muligens ligger _mer_ tilrette i et smidig prosjekt er en annen side av saken. Et produkt er ikke levert, selv ikke under fossefallsmetoden, dersom prosjektet er “styrt mot tid og kost, i stedet for å fokusere på høy kvalitet” som de står i artikkelen.

    Dersom prosjektet inneholder en gigantisk leveranse til slutt, og avtalen er av type fastpris/fossefall, må man planlegge for dette tidlig. Det blir feil å i etterkant skylde på at kontrakten i utgangspunktet er feil. Man er ved sin fulle rett til å si nei til et oppdrag dersom man ikke er enig i kontraktsformen. Dette er en rettighet både leverandør og tilbyder har.

    Jeg skjønner at det er vansjelig å si nei til en kontrakt med verdi på over 500 millioner, men det er en helt annen sak.

    • Written by Terje
      on 16/04/2012 at 4:17 pm
      Reply · Permalink

      Enig i at mer tradisjonelle tilnærminger som fossefall ikke betyr at man ikke kan levere kvalitet i alle tilfeller, men problemet er jo gjerne at det viser seg gang på gang at man på et eller annet tidspunkt styrer mot tid og kost – selv om det ikke er intensjonen. Kanskje har man estimert for dårlig eller vært for grådig. Kanskje har en fått uforutsette utfordringer underveis. Det er mange grunner, men resultatet er ofte det samme: En må kutte hjørner når en etterhvert nærmer seg sluttdato og det vil som regel være kvaliteten det går utover. En har ikke like god til å implementere gode utviklingsteknikker, og en dropper ofte viktige prinsipper som å refaktorisere og skrive god kode med gode nok kommentarer. En del dropper systemtesting – spesielt å utføre gode nok stresstester, noe som for systemer av Altinns størrelse er alvorlig nok i seg selv.

      Derav mine kommentarer om at det kan være lurt å la prosjekter som er mindre og mer oversiktlige kjøre et mer tradisjonelt løp og la prosjekter med mer risiko og uoversiktlighet kjøre et mer agilt løp. Til syvende og sist spiller det totalt sett ingen rolle hvem som har skylden. Poenget og det overordnede målet må være å arbeide for å minimere cowboytankegang fremfor å finne syndebukker, enten de er blant leverandør eller kunde.

Subscribe to comments via RSS

Leave a Reply