I et av de neste møtene i Comunita skal vi snakke om prosjektporteføljestyring i et ekspanderende marked – og dette er et (nokså foreløpig) bakgrunnsnotat.

Latinen^* ovenfor kan oversettes med omtrent “Hvem skal passe på dem som passer på” og er forfattet av den romerske satirikeren Juvenal. Og årsaken til at det står her, er at denne situasjonen, noe omskrevet, er vanlig i mange bedrifter.

Konteksten denne gangen er en stor norsk virksomhet som bygger og driver infrastruktur, og som står i en situasjon der deres prosjektportefølje blir tidoblet i perioden 2022-2027. Dette skjer samtidig som deres innflytelse over underleverandører reduseres, siden den samme ekspansjonen skjer i mange andre land i Europa og leverandørene har mer enn nok å gjøre.

En tidoblet portefølje betyr ikke at man bare kan øke egen organisasjon ti ganger, særlig ikke i et marked der det er økt konkurranse om ressursene. Man må jobbe smartere, ikke bare mer. I hovedsak får man til dette ved å stole mer på leverandørene og deres standardteknologi (noe som allerede har skjedd i oljeindustrien), ved å standardisere prosjektmetodologien, og – og det er det vanskeligste – å outsource byggherreansvaret til eksterne leverandører.

I praksis betyr dette at man går fra å styre prosjekter selv til å styre de som styrer prosjektene – derav overskriften.

Dette høres jo logisk og greit ut, men djevelen ligger som vanlig i detaljene. Hvilke prosjekter skal du gjøre selv, og hvilke skal du sette ut? Hva skal forskjellen være i hvordan du styrer dem?

I praksis handler det om å forstå hva som karakteriserer prosjekter, finne kategorier, for så å tilpasse hvordan man styrer dem ut fra hver kategoris egenskaper.

Prosjektstyring: Prosess versus fleksibilitet

Det finnes mange modeller for styring av store prosjekter. Den vanligste (i Europa) heter PRINCE2 og er noe man kan bli sertifisert for. I USA heter det mest vanlige rammeverket PMP. Begge er modeller som definerer prosjektdimensjoner som må styres , dokumentasjon som må lages, og, fremfor alt, en prosess der prosjekter deles opp i underprosjekter. Begge metodene er svært tradisjonelle, men fungerer utmerket i situasjoner der man vet hva man skal bygge, har ressurser og et relativt stabilt verdiforslag for prosjektet gjennom hele dets levetid.

Slike prosessorienterte modeller er viktige først og fremst fordi de representerer en måte å dele opp elefanten på (man kan som kjent spise en elefant, en bit av gangen). Prosjektet deles opp i deler (kalt, for eksempel, work packages), som byggeblokkene i det større prosjektet, og som har klart definerte sluttpunkter (i likhet med hele prosjektet). De er først og fremst definert ut fra funksjonalitet – i praksis en komponent av noe større, en modul, og fungerer utmerket i de situasjoner (og det er de fleste) der hele prosjektet kan deles opp i moduler ut fra en forhåndsgenerert produktbeskrivelse.

Når vi bygger et hus, en vei, en boreplattform eller, for den saks skyld, en batterifabrikk , vet vi hva vi ser på. Digital teknologi tillater også en økt kompleksitet i selve produktet og stor fleksibilitet i hvem som utvikler de ulike delene – fordi en digital prototype (som senere blir en digital tvilling) kan aksesseres av mange, er billig å produsere, og gjør at man kan teste avhengigheter tidlig. Ikke minst kan man gjøre raske og billige eksperimenter tidlig i en prosjektfase, der de fleste feilene gjøres.

En annen måte å styre et prosjekt på, mye brukt innenfor softwareutvikling, er ulike former for agile metoder. Hovedproblemet med software versus hardware er at det er nokså lett å lage et bilde av hardware som alle kan samles rundt: Når man står og ser på et modell (digital eller fysisk) av en ny bil, fly, vei eller hus, er det liten uenighet om hva man faktisk ser. For et system blir gjerne modellen i praksis papirbasert: Bokser med piler og linjer mellom. Står man foran en tavle – digital eller fysisk – med masse Post-It notes, er det mye vanskeligere å bli enige om hva man ser, og det tar mye lenger tid å forstå helheten.

Det er derfor moderne softwareutvikling er preget av eksperimentering: Man begynner med å lage en minimumsmodell (ofte kalt MVP eller minimum viable product) som man viser til kunder eller brukere, får tilbakemelding på og så lager på nytt. Prosessen gjentas inntil alle er fornøyd eller budsjettet er brukt opp, og overgangen mellom utvikling og implementering er gradvis. Oppdelingen av prosjektet er først og fremst basert på tid: Man gjør så mye man kan innenfor en relativt kort tidsperiode, tester det, og tar så fatt på neste, korte tidsperiode.

Fra prosjektstyring til prosjektportefølje

Å styre mange prosjekter er ikke det samme som å styre ett, men det er visse likheter, ikke minst i at man forsøker å spise elefanten ved å dele den i håndterbare deler. Vanskeligheten med å styre prosjektporteføljer er, i hvert fall slik jeg ser det, først og fremst et spørsmål om hvilke kriterier man skal bruke for å dele opp prosjektene.

I utgangspunktet kan man ha ganske klare kriterier for å kategorisere prosjekter – som kostnad, verdi, risiko, tid, ressurser (ofte vanskelig å vurdere, man ender gjerne opp med ulikheter i belastning), geografi, kundegruppe, eller strategi (etter mitt syn, hvor nært kjernevirksomheten prosjektet ligger). Dimensjonene, hva man nå velger, er førende for hvordan prosjektene skal styres.

Innenfor softwareutvikling finnes det gode modeller – min personlige favoritt er Weill og Ross’ modell som deler IT-prosjekter inn i kategorier med tilhørende finanierings- og styringsmodeller:

• infrastruktur (sentralt finansiert, styres av teknologene)
• transaksjonelle (bruksfinanisert – f.eks. per transaksjon, styres sentralt)
• informasjonelle (betales for og styres av de som har bruk for informasjonen)
• strategiske (et noe upresist begrep, men det henspiller på konseptuell usikkerhet, og styres som en ventureportefølje, der noe vil gå dårlig men verdien av hele porteføljen er høy)

En agil prosjektstyringsmodell – mange agile prosjekter – handler mer om å styre ut fra hvem og hva som er involvert. Prosjektporteføljestyring basert på agile metoder er, så vidt jeg vet, ikke helt etablert ennå, i hvert fall ikke med samme detaljeringsnivå som tradisjonelle prosjekter. Fokuset er i alle tilfeller på å lage grupper av ansatte rundt det som skal utvikles – DNB, for eksempel, snakker om familier rundt funksjonalitet – med få eller ingen handovers og konsistens håndtert ved at personale følger prosjektet gjennom alle faser til det tas i bruk.

Det er vanskelig å peke på gode modeller for kategorisering av prosjekter som ligner på hverandre (som byggeprosjekter), men størrelse og kompleksitet er i alle fall to dimensjoner å tenke på: Størrelse fordi store prosjekter er en risiko i seg selv, kompleksitet fordi komplekse prosjekter kan konsumere ressurser langt utover det størrelsen skulle tilsi. Problemet er ofte at det er lett å måle størrelse, men vanskeligere å måle kompleksitet.

Personlig liker jeg å tenke at kompleksitet kommer i ulike dimensjoner. Et produkt eller prosjekt kan være komplekst fordi det er stort, kostbart eller inneholder mange komponenter. Men kompleksitet kan også forstå som noe konseptuelt – de farligste prosjektene er de man ikke har gjort før, eller de der målbildet er dårlig definert.

Et praktisk eksempel

I et porteføljestyringsprosjekt jeg var med på for noen år siden (stort amerikansk industrikonsern som måtte kutte sine IT-prosjekter med 25%) kom jeg opp med en modell som definerte to dimensjoner: kostnad og verdi. Begge deler kan ha gode mål, men det er problemer:

• budsjetter tenderer til å inneholde “sunk cost”, og blir dermed vanskeligere å stenge
• risiko undervurderes, og er ikke reflektert i kapitalkostnaden
• infrastrukturverdi – det at alle kan bruke en teknologi, og du ikke vet hva den kommer til å brukes til – er vanskelig å verdsette
• konkurransefortrinn kan være store, men man undervurderer ofte hvor fort de eroderer
• organisasjonsrisiko – i hvilken grad organisasjonen er i stand til å vurdere enkelte prosjekttyper riktig – er sjelden målsatt

Prosjektet gjorde et forsøk på å målsette dette, ved å sette opp en modell som parameteriserte endel av disse tingene, som infrastrukturverdi (hvor stor del av organisasjonen som ville trenge prosjektet) og organisasjonsrisiko (hvor kom forslaget fra – jo lavere i organisasjonen, jo mindre risiko). Alt ble kjørt inn i en matrise, og så kunne man flytte på aksene i den resulterende 2 x 2-matrisen inntil man hadde funnet de 25% som skulle kuttes.

En fordel med en slik metode er at man kan diskutere hvor mye vekt hver faktor skal ha, man kan behandle alle prosjekter likt, og resultatene er nokså entydige. Dermed blir det lettere å få enighet om prioriteringer.

Outsource og deleger det du kan, behold det du er usikker på

Et gammelt visdomsord sier at når du starter et firma og etterhvert skal ansette folk i firmaet dit for å gjøre det du kan godt selv – for det du kan gjøre, kan du styre. Kanskje begynnelsen på prosjektdelegering ligger i å sette bort det du kan beskrive, og så beholde styringen på det som du ikke helt skjønner hvordan du skal gjøre selv?

Det vil i alle fall sikre at du ikke kan legge skylden på noen andre, skulle det gå galt.

_{*Ja, jeg vet latin er pretensiøst, men det er morsomt å forsøke å virke sivilisert en gang i mellom…}