Prosjektets tre problemområder

Prosjektet er en godt egnet arbeidsform når vi trenger å løse et konkret problem som krever målrettet innsats og fokus. Det er en helt opplagt organiseringsform når noen skal levere et konkret produkt, som for eksempel en bygning, eller en veistrekning. Det gjelder da å stable på beina en midlertidig organisasjon som er kompetent til å levere resultatet innen en bestemt kostnadsramme og tidsfrist. Når da resultatet til slutt foreligger, får prosjektet et oppgjør, vi oppløser prosjektorganisasjonen og resultatet går over i en vedlikeholdsfase.

Prosjektet hviler på et helt spesielt tankesett som innebærer at bare vi bruker gode nok metoder og nok tid i planleggingsfasen, vil gjennomføringen gå greit (selv om vi vet at det vil komme endringer underveis som vi må håndtere). Innovasjonen foregår på forhånd, i oppstartsfasen. Prosjektet innebærer at vi forplikter oss til å levere hele produktet. Det er med andre ord mye penger på spill, så det er viktig å ikke feile!

 

Prosjektet

Prosjektet og vedlikehold

Jeg forstår godt at prosjektledere og -eiere også benytter seg av denne arbeidsformen innenfor IKT-relatert arbeid, selv om programvareprodukter er ganske forskjellig fra en bygning. Hvorfor skulle det ikke fungere fint også for programvareutvikling? Vel, det kunne kanskje vært en ide å spørre de som egentlig kan faget: utviklerne…

OK, det er altså tre problemer med prosjekt som arbeidsform…

Problem nummer 1: Oppstart

Tankesettet her er at nå må vi forstå hele problemet godt nok til at vi kan definere sluttleveransen. Vi bruker god tid på å spesifisere, analysere og planlegge slik at vi ikke får overraskelser underveis. Så er det å legge det hele ut på anbud og finne den beste (gjerne billigste) leverandøren. Denne forplikter seg så til å levere iht en plan og til en avtalt pris. Denne leverandøren får da en ny oppstartsfase før de kommer igang med selve utviklingen.

Hva er så problemet med dette?

Siden vi forplikter en komplett leveranse, innebærer et prosjekt alltid en stor økonomist risiko. Derfor må vi logisk nok gjøre grundig forarbeid. Dette må nødvendigvis ta mye tid – ofte så mye tid at verden rundt oss rekker å forandre seg mens vi jobber! Dessuten vet vi jo nå av erfaring at det på tross av denne grundigheten klarer vi ikke å unngå stor risiko. Uventede ting skjer garantert! For å få framdrift i denne fasen får vi et stort behov for å forenkle og “spikre ting”. Dette gjør at vi låser oss til en mengde antagelser som blir en del av spesifikasjonen.

Resultat: En sanseløs bruk av tid, som gir svært begrenset verdi. Vi bygger antagelser inn i spesifikasjoner, baserer oss på svært usikre estimater (som alle er multiplisert med en faktor) og har skaffet oss en ganske ustyrlig kompleksitet.

Problem nummer 2: Gjennomføring

Når man lager fysiske ting kan man enkelt og intuitivt følge framdriften med egne øyne. Det er også fullt mulig å gjøre kvalitetssjekker av konkrete delleveranser underveis og dette gjøres (selvsagt) i stor grad. Når produktet er programvare er dette helt annerledes, siden det eneste synlige ligger i det tynne skallet på toppen som vi kaller “brukergrensesnittet”.

Hva er så problemet med dette?

Hele prosjektet jobber mot en komplett leveranse, så det er slett ikke gitt at det foreligger delleveranser. Derfor er man prisgitt en svært teoretisk framdriftsmåling og kvalitetsvurdering. Prosjektstyringsmiljøet har funnet på ulike regimer som er ment å gi styring og innsikt i framdriften. Earned Value er et slikt eksempel. Men gir dette navnet mening? Har det noe med opptjent verdi å gjøre? Nei, dette sier egentlig bare noe om forbruk av penger! Ikke noe feil med å følge med på pengeforbruk selvsagt, men dette kan lett gi en falsk trygghet. Og så kan vi følge opp framdrift mot en milepælsplan med tilknyttede estimater. Dette er også en svært teoretisk form for styring, selvsagt. Hvor gode er estimatene egentlig? Og hvordan vet vi egentlig om en milepæl er helt oppnådd? Problemet nå er selvsagt at vi ikke fullfører noe synlig funksjonalitet underveis. Det er tross alt synlige, konkrete resultater som vil kunne gi oss verdifull informasjon om framdriften. Og ikke minst om kvaliteten!

Og så er det alle endringene. Leverandøren vil være interessert i mange endringer både fordi de er godt betalt, men også fordi det vil være en betimelig unnskyldning om framdriften skulle være for dårlig. Sett fra kunden er endringer kilde til galopperende kostnader og utsettelser. Dessuten er formell endringehåndtering kostbart.

Resultat: Et kostbart styringsregime som er teoretisk og ikke er egnet til å vise den egentlige statusen til prosjektet, samtidig som kostnadene uansett galopperer avgåde på grunn av alle endringene.

Problem 3: Avslutningen

Slutterminen er sannhetens øyeblikk for et prosjekt. Alle krefter settes inn på å få leveransen akseptert, slik at prosjektet kan få betalt. Alle prosjekter er nå i en slags unntakstilstand. Uventede ting har ganske riktig forekommet i rikt monn. Estimater var optimistiske. Så nå gjelder det å finlese kontrakten og jobbe hardt mot ett formål: At akseptansetest og sluttkontroll skal gå igjennom. I de siste ukene er det om å gjøre å “pynte brura” og bare bruke kreftene på det som er helt nødvendig.

Når prosjektet da til slutt har lappet sammen en leveranse, vil denne ofte være beheftet med dårlig kvalitet. Mye av kvaliteten ligger som kjent gjemt langt under overflaten i programvareprodukter, så det er håpløst for kunden å vurdere om dette produktet er vedlikeholdsvennlig. Vedlikeholdsvennligheten er den viktigste faktoren til et produkts livsløpskostnad.

Dessuten er det først nå vi får testet antagelsene som ligger innebygd i spesifikasjonen. Har vi løst riktig problem? Får vi de gevinstene vi kalkulerte med? Er ytelse og brukervennlighet bra nok?

Resultat: Prosjektet blir godkjent og får betalt, produktet overleveres til drift- og vedlikehold slik at alle manglene kan rettes opp. Denne “vedlikeholdsfasen” blir svært kostbar og tung, siden prosjektet har etterlatt seg kode som ikke følger de beste håndtverksmessige standarder. Hvorfor skulle de det, egentlig? Denne midlertidige organisasjonen blir målt på leveransetidspunktet, ikke på det langsiktige livsløpet.

For ordens skyld: Det er ikke nødvendig å utvikle IKT-systemer med prosjekt. Bare nevner det.

Posted on November 25, 2014 at 4:18 pm by gamsjo · Permalink
In: prosjektledelse, Samfunn, Uncategorized · Tagged with: , , ,

One Response

Subscribe to comments via RSS

  1. Written by Det smidige hjørne » Er “prosjekt” alltid riktig verktøy?
    on 13/11/2016 at 11:04 am
    Reply · WordPress › Error