Prosjekter fungerer utmerket for oppføring av konkrete reisverk; som bygninger eller broer. Likeså for utvikling av løsninger til konkrete engangs-hendelser som vi vet inntreffer på et bestemt tidspunkt. Hvor deadlines er absolutte, og ikke for langt frem i tid. F.eks. utforming av deltagerlandsbyen til neste års OL. Prosjekter av natur er tuftet på en «alt eller ingenting» mentalitet. Problemene melder seg idet man introduserer fiktive begrensninger for å passe prosjektformen.
Med fiktive begrensinger mener jeg hjørnene i det velkjente prosjekt-triangelet: tid, kost, og omfang (scope). Det er mye lettere å måle prosjektets fremgang mot disse parameterne enn det som virkelig betyr noe, og derfor blir det også gjort. Prosjekt skaper en illusjon av forutsigbarhet.
Man trenger ikke lengre treffe på sine spådommer gjort flere år tilbake i tid. Forutsetningene og samfunnet rundt oss endrer seg mye raskere enn som så. Evnen til å agere raskt er viktigere enn å holde seg til en plan for å kunne være konkurransedyktig i fremtiden.
Prosjekter har, som nevnt, ofte en tendens til å bli målt på dets evne til å treffe med de initielle nedtegnelsene. Man definerer suksess hvis prosjektet er ferdig til avtalt tid og avtalt kost. Dette er fullstendig meningsløst. Man kjører ikke prosjekter for prosjektets skyld. Forretningsverdien prosjektet forhåpentligvis har og vil fremskaffe fremover er sjelden tatt med i beregningen. Det burde vært motsatt. Verdien som genereres gjør tidsrammene og kostnadsrammene irrelevante. Hva man spådde for flere år siden gir ikke lengre mening. Og når måler man egentlig verdien? Idet prosjektet avsluttes? For det første er det altfor seint, for det andre er det altfor tidlig. Hva hvis forutsetningene har endret seg slik at forretningsverdien er negativ, men man har allikevel truffet på tid og kost? Er det ikke bedre å få raskere tilbakemeldinger og heller terminere eller endre kursen på et så tidlig tidspunkt som mulig?
Programvare-utvikling er i sin natur uegnet til å passe inn i et prosjekt. Programvare er ytterst sjelden temporær, og kompleksiteten og kostnadene til programmer begynner først på alvor når de er rullet ut og i skarp drift. Dette er gjerne på samme tid som prosjektene er i ferd med å avsluttes.
Man skal ikke definere en slutt-dato for programvare. Isteden skal man forvalte og videreutvikle denne så lenge som det genererer størst mulig forretningsverdi for eierne. Ideelt bør man kunne fortsette sålenge det gir mer verdi tilbake enn det koster, men knapphet på ressurser kan gjøre at det går på bekostning av andre mer verdifulle oppgaver.
Kvalitet i programvare er alfa og omega. Kvalitet i det som lages i temporære prosesser er mindre viktig. Det er kvaliteten som må vike når det kniper på triangelets kant-verdier, eller de fiktive milepælene for å komme dit.
En populær prosjektmetode er PRINCE2. Hvis da en markedsandel på 3% kan kalles populært. Pga smidige metoders enorme innflytelse har PRINCE2 og andre metodeverk for prosjektgjennomføring dratt inn elementer av iterative og inkrementelle faser på innsiden av dets faste rammer. Man kommer et stykke på vei, men det er og blir sub-optimalisering. For å ta en analogi til programmering: innføringen av objekt-orientering til et allerede eksisterende språk slik som c og python. Resultatet og gevinstene uteblir. Med utvikling av programvare i dag (som ett av mange områder) så har man mulighet til å levere reell verdi tidlig. Man har mulighet til å få feedback tidlig. I dag kan man initiere et team og så ganske raskt få kontinuerlig verifisert den antatte verdiøkningen, og slik justere kursen og målet fortløpende.
Man trenger ikke lengre en stor commitment up-front, med godkjenning fra øverste hold, budsjetter og bevilgninger, milepæler, detaljerte prosjektplaner, med mye mer, før man starter (sin uttesting av hypotesen). Dermed trenger man heller ikke et stort forprosjekt for å rede grunnen til prosjektet. Om ikke forprosjekt koster mye i form av ressurser, så forbruker det dyrebare kalendermåneder som kan være kritisk i forhold til markedet og konkurranseevnen. For alternative finansielle instrumenter, anbefales Implementing Beyond Budgeting av Bjarne Bogsnes.
Det er forsket på effektiviteten til mennesker som organiserer seg i teams. Noe man sikkert også har erfart selv, er at det tar tid for et nytt team å bli virkelig effektivt. Man må bli kjent, virkelig kjent, man må bygge opp en felles domene-forståelse, en felles måte å jobbe sammen på, og en må finne sin naturlige plass i det sosiale hierarkiet. Det er dumt å avslutte prosjektet og oppløse teamet idet teamet virkelig har fått opp dampen.
Overlevering av programvare fra et utviklerteam i prosjektet til et forvaltningsteam i linjen er standard prosedyre og kommer som følge av prosjekt-modellen. Dette er en særdeles dårlig ide, og bærer med seg flust av skjulte kostnader.
Det finnes alternative måter å gjennomføre endringer på. Spørsmålet er bare hvor en skal begynne? Hvordan løses konkrete behov som f.eks. kontinuerlig gevinst måling og evaluering av nytte underveis? Dette ønsker vi å komme tilbake til i en senere artikkel. Enn så lenge har vi her et par start-referanser for videre utforskning:
- https://www.amazon.com/Implementing-Beyond-Budgeting-Unlocking-Performance/dp/111915247X
- https://www.infoq.com/noprojects/
Å starte et eget Prosjekt som ser på dette, kan anbefales! Fortsettelse følger…