Codex X12: Helheten i en prosjektmodell Byggebransjen er inne i den fjerde industrielle revolusjonen og på vei mot mer heldigitale produkt-sykluser. Dette vil føre til nye kontrakts- og samarbeidsformer. Bransjen mangler en velegnet prosjektmodell som kan være et verktøy i denne omstillingen. En prosjektmodell er det verktøyet som samstemmer aktørene og definerer prosesser, leveranser og beslutninger. De modellene som i dag benyttes til store offentlige prosjekt fremstår som utydelige og mangelfulle. Det gjennomføres mange gode prosjekter i byggebransjen, men det gjennomføres også mange prosjekter med mindre gode resultater. Dette kan være i form av at feil bygg bygges, bygg innehar ikke-optimale løsninger eller at produktet ikke får den standard og kvalitet en kan forvente. Det kan også være i form av overskridelser av kostnad eller planlagt tidsforløp. En fremtredende grunn til at prosjekter blir gjennomført med mindre gode resultat er mangel på en prosjektmodell som er styrende for gjennomføringen og kontrollerende for resultatet. Mangel på en fungerende modell vil i mange tilfeller føre til at prosjektgjennomføringen blir mer tilfeldig basert på den enkeltes kompetanse og erfaringer. Les også: - Samfunnet vil spare milliarder med riktig prosjektmodell Fant ingen som var velegnet I søken etter en velegnet modell har vi evaluert en rekke prosjektmodeller basert på fire enkle kriterier: · Enkel å forstå, lett å kommunisere · Alle hovedtemaer skal være egne faser · Alle hovedbeslutninger plasseres i overgang mellom faser (dvs. når beslutningsunderlag foreligger) · Modellen kan tilpasset ulike samarbeids-/entrepriseformer Resultatet fra analysen var at ingen av de analyserte modeller fremstår som velegnet. Tar vi et steg videre og omdefinerer prosjektmodellen til en prosjektledelsesmodell, vil dette ytterligere skjerpe kravene ut over de fire overnevnte kriteriene. Dette vil stille krav til å knytte modellen opp mot organisasjon og organisasjonsnivåer, med definering av kompetanse og tilhørende beslutningsmatrise. Siden vi ikke fant en modell som kom godt ut med våre kriterier har vi valgt å bygge opp en ny modell helt fra bunnen. Denne nye modellen har fått navnet Codex X12. Helheten i en prosjektmodell En prosjektmodell skal som nevnt være styrende for gjennomføringen og kontrollerende for resultatet. Vi hevder at byggebransjen mangler en fungerende modell for dette. Med det som utgangspunkt, la oss se på hva en slik modell bør inneholde. Det mest sentrale i en prosjektmodell er faser og beslutninger, men det er også flere andre viktig forhold som også må tas inn i en helhetlig modell. Faser er en gruppering med aktiviteter eller utredninger, som ferdigstilles innenfor en tidsfase, og har en definert start og slutt. Prosesser er aktiviteter som skiller seg ut ved at de pågår over flere faser i prosjektet. Eksempler på dette er ledelseprosesser, planlegging, innkjøp og organisering av kompetanse og kapasitet for neste og påfølgende faser, utvikling av prosjektkostnad, påløpte utredningskostnader, mv. Beslutninger er det som former prosjektresultatet mer enn noe annet. De store beslutningene plasseres i etterkant av en fase der utredning og beslutningsgrunnlaget foreligger. Kontroll i faseovergang er prosjekteiers viktigste oppgave og inngår som en del av beslutningene i prosjektmodellen. Kommunikasjonsnivå definerer de ulike rollene i prosjektet og kommunikasjonen mellom disse. Kontrakt fordeler risiko og angir partenes ansvar, forpliktelser og godtgjørelser. En kontrakt defineres ut fra hvem som deltar som kontraktspartnere og i hvilke faser i prosjektet de deltar. Kontrakt og samarbeidsmodeller er i Codex X12 integrert inn mot prosjektmodellen. Kompetansesammensettingen angir når ulike kompetanser tas inn i prosjektet. Ulik kompetansesammensetting vil gi ulikt prosjektresultat. Kompetansesammensettingen er derfor en kritisk faktor i forhold til å sikre gode prosjektresultater. Offentlige godkjenninger innhentes basert på avklaringsnivå i prosjektet. Dette knyttes opp mot fasene i modellen. Ved å inkludere forholdene nevnt ovenfor får vi en mer komplett prosjektmodell: En modell som blir styrende for gjennomføringen og kontrollerende for resultatet. Alle disse forholdene blir gjennomgått i senere artikler. La oss se hvor dette fører oss. Neste artikkel om Codex X12 publiseres tirsdag 14. april. Der ser vi nærmere på prosjektfaser.

Codex X12: Kostnadssprekk og konflikter skyldes ofte utydelig definerte prosjekter De viktige fasene i en prosjektmodell Hva er konsekvensene av å gjennomføre byggeprosjekter uten en fungerende prosjektmodell – en modell som er styrende for gjennomføringen og kontrollerende for resultatet? Vi ser nærmere på fasene i et prosjekt, kronologisk oppbygget i prosjektmodellen Codex X12. La oss starte med et par eksempler: Mange prosjektmodeller tar ikke med det utløsende behovet, det som leder frem til bestilling og oppstart av et prosjekt. Dette vil kunne gi en uklar bestilling, noe som kan føre til at det utvikles bygg med ikke-optimale løsninger for bestiller og bruker eller at feil bygg bygges. Utløsende behov og bestillingen er omhandlet i fasene X1-X3 nedenfor. En annen kjent problemstilling er at tidligfase i prosjekter er utydelig definert, noe som fører til manglende avklaringer inn mot detaljprosjekteringen. Det fører videre til manglede underlag for produksjon på byggeplass og hos leverandør. Denne problemstillingen er forløperen til et stort antall av de juridiske konfliktene i bransjen. Tidligfase i prosjekter er omhandlet i fasene X4-X8 nedenfor. Prosjektmodellens hovedfaser Ser vi nærmere på strukturen i en prosjektmodell vil det være naturlig å dele denne opp i en hovedinndeling og deretter i underliggende faser som i kronologisk rekkefølge tar for seg alle hovedtemaer i et prosjekt. Hovedinndeling deles inn i følgende fire deler: A. Innledende del, den som leder frem til hovedprosjektet. B. Tidligfase prosjekt (forprosjektet). C. Produksjonsfasen for produktet. D. Garanti – gevinstrealisering – FDVU. Hovedinndelingen samstemmer med eier av fasen. Første og siste del tilhører virksomheten. Første del er før tidligfase prosjekt er besluttet iverksatt. Siste del er etter at virksomheten har tatt over/tatt i bruk bygget. Tidligfase prosjekt og produksjonsfasen tilhører prosjekteier eventuelt fordelt på henholdsvis prosjekteier tidligfase og produksjon. Codex X12 kan nyttes innen mange ulike bransjer. I denne beskrivelsen rettes den mot bygg. Den viktige innledende delen Innledende del (A) har tre faser (X1-X3). X1: Den første fasen definerer «Utløsende behov eller virksomhetsbehovet». Dette kan være i form av et behov for en modernisering av infrastruktur eller som følge av nye strategier eller markedsplaner. Et slikt behov kan være en ny produksjonskapasitet med tilhørende behov for lokaler. X2: Den andre fasen er «Mulighetsstudie & alternativanalyse for konsept». Vi ser her på ulike muligheter for å svare ut utløsende behov. Disse mulighetene kan være i form av å kjøpe inn aktuell vare og tjeneste (outsourcing), eller med en egenproduksjon som krever leie, kjøpe, bygge om eller å realisere et nytt bygg. I offentlige prosjekter (over 700 mill.) omfatter denne fasen først KVU (Konsekvensvalg utredning) og deretter KS1 (Kvalitetssikring-1 som er en kontroll av KVU utredningen). X3: Den tredje fasen er «Rammer og føringer for prosjektet». Denne fasen skal definere hva som er bestillingen til prosjektet. Det kan omfatte krav til virksomhetsmål og gevinster, design og uttrykk - og ikke minst til kostnadsrammer, fremdrift og gjennomføringsstrategi. Dette kan være krav til teknologi nivå, energi og bærekraftmål, krav til virksomhetsutvikling og tjenestedesign for å fremme fremtidsrettede løsninger, mv. Fasen leder frem til et underlag for en beslutning om oppstart av prosjektet. For offentlige prosjekter (over 700 mill.) har finansdepartementet stilt krav til en slik fase som ender ut i beslutningen OFP (Oppstart For Prosjekt). Mer om tidligfasen i prosjektet Tidligfase prosjekt (B) har fem faser (X4-X8). X4. Den fjerde fasen, «Design basis - Program for bygg», omfatter å definere alle forutsetninger for hovedfunksjonalitet og utforming av bygget. Her inngår rammer og føringer fra behovseier (X3), rammeforutsetinger fra myndigheter, valg av standarder (f.eks. energistandard), avklare alle behov og krav til virksomhet-/brukerfunksjonalitet og frem til utarbeidelse av et rom- og byggeprogram. Fase (X5) og (X6) er fasene for å fastsette arkitektur. X5 Fasen, «Arkitektur - Mulighetsstudie & Alternativ analyse», omhandler i først del et mulighetsstudie der man frembringer alternative løsninger og utforminger for et bygg som tilfredsstiller føringer fra fasen (X4) «Program for bygg». Andre del omhandler en analyse av de alternative løsningene opp mot forutsetninger, økonomiske forhold, helhet, usikkerhet, mm. - helt frem til en innstilling for valg av løsning. X6 Fasen, «Arkitektur – Hovedarkitektur», handler om å utvikle valgt løsning til en komplett helhet med brukerfunksjonalitet, plasseringer av bygg og hovedstrukturer, hovedføringer, plan, snitt, fasade og uttrykk. I fasen inngår å frembringe kostnad og styringsramme for valgt løsning. Fase (X7) og (X8) er fasene for å fastsette teknisk funksjonalitet i bygget. X7 Fasen, «Funksjoner - Definere krav til funksjon», omhandler å definere ytelseskrav til all funksjonalitet i bygget (tekniske kravspesifikasjoner). X8 Fasen, «Funksjoner - Valg av løsning», omhandler å fremme alternativer og velge løsninger og produkter, for å innfri funksjonskravene fra fase X7. Kort om produksjonsfasen Produksjonsfasen (C) for prosjektet har tre faser (X9-X11). X9 Fasen, «Produksjon – underlag», omhandler tradisjonelt produksjon av arbeidstegninger. Dette vil fremover bli erstattet med produksjon av BIM-modeller og underlag for automatisert produksjon og leveranse. Det legges til grunn som hovedprinsipp at alle beslutninger er gjennomført i tidligfasene X4-X8. X10 Fasen, «Produksjon av bygg». Denne fasen omfatter tradisjonelt sett produksjon av bygg på byggplass. Men fasen er i endring til at en stadig større del av produksjon går over til en prefabrikasjon hos produsent, og til at byggeplassen omfatter montasje. X11 Fasen, «Produksjon – Idriftsetting», omfatter idriftsetting og innkjøring av bygg og tekniske anlegg, utbedring av mangler, og sikre at løsningen innfrir forventede funksjonalitet. «Garanti – gevinstrealisering - FDVU», fasen (D) X12 Fasen, «Garanti – gevinstrealisering - FDVU», omfatter garantiaktiviteter og gevinstrealisering og FDVU. Garanti rettes mot bygg og tekniske installasjoner. Gevinstrealisering innebærer å planlegge og organisere med tanke på å hente ut gevinster av et tiltak, og å følge opp disse gevinstene slik at de faktisk blir realisert (Direktoratet for forvalting og økonomistyring). Noen av disse tiltakene rettes mot bygg. Andre er innenfor virksomheten. FDVU omfatter avtalte ytelser i kontrakt. Fasen varer så lenge forpliktelser fra prosjektet strekker seg etter avsluttet prosjekt. Dette styres av kontrakt og lovverk. Vi har ovenfor gått gjennom hovedinndeling og faser i prosjektmodellen. En god struktur vil her være avgjørende for produktresultatet og kostnader. I neste artikkel, tirsdag den 28. april, skal vi se nærmere på beslutninger knyttet til Codex-X12. Beslutninger er det som former prosjektresultatet mer enn noe annet. Gikk du glipp av første del? Les også: Codex X12: Helheten i en prosjektmodell

Codex X12: Hvor ofte ender byggeiere opp med feil bygg? Beslutninger i en prosjektmodell. Mange prosjekter mangler gode beslutningsstrukturer. Dette vil i flere tilfeller kunne føre til feil løsning for eier og bruker av bygg. I ledelseslitteraturen uttrykkes det ofte at «det er bedre å ta en feil beslutning enn ikke å ta en beslutning». Å være beslutningsdyktig er sett på som en styrke. Men dette klinger ikke godt når konsekvensene er store av feilbeslutninger – og definitivt ikke når dette er noe som kan settes i system og løses. Her er to byggeprosjekter som illustrerer problemstillingen: Det gjennomføres en totalrehabilitering PwC-bygget i Barcode allerede etter 12 år. I 2020 ferdigstilles det et nytt stort bygg for Brønnøysundregisteret med plass til 500 ansatte, i en tid der mange slike arbeidsplasser automatiseres bort – og i et lite lokalsamfunn der et slikt bygg har begrenset alternativ bruk. Det er interessant å stille spørsmålet om andre utrednings- og beslutningsmodeller ville kunne gitt løsninger som kommer bedre ut når det gjelder fleksibilitet og levetid - og ikke minst sett fra et økonomisk, samfunnsøkonomisk og bærekraftperspektiv. Beslutninger er det som former prosjektresultatet mer enn noe annet. Dette er satt i system i Prosjektmodellen Codex X12 og i matrisen Beslutninger X12. I Beslutninger X12 inngår følgende: 1. Virksomhetsbeslutninger 2. Hovedbeslutninger i prosjektet 3. Faseoverganger 4. Løpende prosjektbeslutninger 5. Offentlige beslutninger (finansdepartementet) I beslutningsstrukturen er alle disse beslutningene plassert i faseoverganger, der underlaget for beslutninger er utarbeidet. Et unntak er løpende beslutninger som foregår internt i fasene. Veien frem til oppstart Virksomhetsbeslutninger (VB) er de beslutningene som leder frem til oppstart av hovedprosjektet, og som senere avslutter prosjektet. Disse beslutningene består av VB1, VB2, VB3 og VB4: VB1: Beslutte tiltak virksomhetsbehov. Et virksomhetsbehov avledes fra et oppstått behov i virksomheten. Dette kan være et behov for modifisering av eksisterende infrastruktur eller komme som følge av nye strategier eller markedsplaner. Dette kan eksempelvis lede frem til behov for en ny produksjonskapasitet. VB2: Beslutte konsept (for virksomhetsbehov). Et konsept for en ny produksjonskapasitet kan løses med å hente inn ny kapasitet gjennom outsourcing, alternativt gjennom egenproduksjon i en innleid bygningsmasse, tilpasning av eksisterende eller i form av ny bygningsmasse. Beslutte konsept vil for offentlige prosjekter være i form av KVU (Konsekvens Valg Utredning) og KS1 (Kvalitetssikring av KVU). VB3: Beslutte oppstart av prosjektet. På dette tidspunktet er alle rammer og føringer for prosjektet definert. For offentlige prosjekt er dette beslutningspunktet definert som OFP (Oppstart For Prosjekt). VB4: Beslutte å overta leveransen og avslutte prosjektet. Beslutningen fattes på en innstilling fra prosjektstyret. Kun to hovedbeslutninger i gjennomføringen De to hovedbeslutningene i selve prosjektgjennomføringen er PB1 og PB2: PB1: Å beslutte hovedarkitektur baseres på utredningen i fase X5 som omfatter en mulighetsstudie og en alternativanalyse. For et bygg vil denne beslutningen fastsette planløsninger, fasader, uttrykk og hovedføringer både for logistikk og tekniske anlegg. Dette er den beslutningen som påvirker sluttresultatet mest. PB2: Beslutte kostnad- og styringsramme og at bygningsmassen skal realiseres. Dette er den endelige beslutningen for realisering av den bygningsmassen som prosjektet omhandler. For offentlige prosjekt er dette beslutningspunktet basert på KS2 (Kvalitetssikring-2). Dette beslutningspunktet plasseres etter fase X6. I offentlige prosjekter plasserer denne etter fase X8. Her kan du lese om de forskjellige fasene i prosjektmodellen Codex X12 Beslutninger i forbindelse med faseoverganger er inndelt i PB3-A, PB3-B og PB4: PB3-A: Beslutte oppstart ny fase basert på at «forutsetningene for prosjektgjennomføringen fortsatt er gjeldende». PB3-B: Beslutte oppstart ny fase basert på at «føringer fra forgående faser, beslutninger, planer og ressurser er avklart». PB4: Beslutte avslutning av fase omfatter en kontroll og godkjenning av fasens innhold før fasen avsluttes. De løpende beslutningene Løpende beslutninger omfatter PB5. PB5: Løpende beslutninger omfatter valg internt i hver fase, der det etableres en egen beslutningsplan for hver av fasene. Eksempel på dette er valg av en rekke funksjonskrav i fase X7, eller valg av løsning og produkt i fase X8. Prosjekter i offentlig sektor har tre beslutningspunkter i prosjektforløpet. Disse er KVU/KS1, OFP og KS2. KVU/KS1: Omfatter å beslutte valg av konsept, samt å beslutte at prosjektet skal videreføres etter gjennomført mulighetsstudie og alternativanalyse for konsept. Disse beslutningene sammenfaller med VB2 (i prosjektmodellen Codex X12). OFP: Beslutte «Oppstart For-Prosjekt» er den endelige beslutningen om å iverksette «Tidligfase prosjekt»(forprosjekt). Denne beslutningen sammenfaller med VB3 (i Codex X12). KS2: Kvalitetssikring-2 gir grunnlaget for den endelige beslutningen om å realisere «bygningsmassen». Denne beslutningen sammenfaller med PB2 (i Codex X12). Matrisen «Beslutninger X12» viser hvem som har ansvaret for beslutninger. Men her må man også avklare hvordan beslutningsprosesser skal organiseres når det gjelder å ta inn riktig og nødvendig kompetanse – og ikke minst hvordan beslutningen skal forankres. En feil beslutning gir et feil produkt. Beslutninger blir da det mest produktkritiske man foretar seg i en prosjektutredning. Å gjennomføre dette uten en struktur som systematisk underbygger riktige beslutninger basert på et solid utredningsunderlag, vil kunne gi store konsekvenser for eier og bruker av bygg. I verste fall kan bygget bli uegnet for brukeren eller et feil bygg for eieren. Et eksempel på dette er «Ni år gammelt Akerbygg på Fornebu kan bli revet». Neste artikkel vil omhandle kommunikasjonsnivåer og hvordan disse er knyttet mot beslutninger i prosjektmodellen Codex X12. Les også de innledende artiklene om prosjektmodellen Codex X12: - Samfunnet vil spare milliarder med riktig prosjektmodell Codex X12 – helheten i en prosjektmodell Kostnadssprekk og konflikter skyldes ofte utydelig definerte prosjekter

Codex X-12: En utydelig organisering av byggeprosjekter er som å be om økte kostnader og et dårligere produkt Organisasjonsnivåer i en prosjektmodell Mange byggeprosjekter er utydelig organisert og har en uklar beslutningsstruktur. Det fører til et stort antall møter, overforbruk av timer og uklare retningslinjer. Summen er et svekket produktresultat. Codex X-12 gir svar på hvordan dette kan unngås. En hovedgrunn til at mange prosjekter er uklare og ineffektive, er at en prosjektorganisasjon er satt sammen av personer og kompetanse fra flere ulike bedrifter og bedriftskulturer. Bruk av titler i bedrifter samsvarer ofte ikke med reelle roller og ansvar i prosjektet. Dette vil i mange tilfeller gi prosjektorganisasjoner med uklare roller og kommunikasjonslinjer. Resultatet av svakt definerte roller og uklare kommunikasjonslinjer blir derfor ofte at «alle» er på kopi, alle deltar på møter og mange beslutninger blir tatt tilfeldig. Direkte overraskende burde det da ikke være at svak prosjektorganisering og uklar deltakelse ofte resulterer i høyt timeforbruk og en haltende fremdrift. I Codex X12 håndteres dette ved at det etableres organisasjonsnivåer der man definerer de ulike rollene i prosjektet og kommunikasjonen mellom disse. Et prosjekt vil normalt ha fem organisasjonsnivåer, der hvert nivå kommuniserer med samme nivå, leder nedover ett nivå og rapportere oppover ett nivå. De strategiske nivåene Tar vi inn virksomheten og prosjekteier får vi totalt åtte organisasjonsnivåer. Disse åtte nivåene er: L0 Virksomhetsledelse/styre Virksomhetsledelsen/styret sitt ansvar er knyttet til å løse viksomhetsbehovet og er representert med de som er tildelt denne myndigheten i virksomheten. Virksomhetsledelsen/styret beslutter VB1, VB2, VB3 og VB4 (se Beslutningsmatrise X12). L1 Prosjektstyret Prosjektstyrets ansvar og oppgaver er generelt knyttet til de tre interessentgruppene virksomheten, leverandører og brukere (kilde: Difi). Prosjektstyrets sammensetning vil være avhengig av kontraktsform, der de kontraktspartnerne som bærer produktansvar normalt vil delta. Tilsvarende vil de som er avhengig av resultatet være representert. Dette vil være eiere av bygget og den virksomheten som bygget skal tilpasses til (brukerne av bygget). Prosjektstyre beslutter PB1 og PB2. Prosjektstyret kan bestå av separate beslutningstakere der hver av disse har muligheten til å beslutte «ikke å realisere prosjektet». Dette kan være virksomheten som skal bruke bygget, de som skal eie bygget og de som skal finansiere bygget. L2 Prosjekteier Prosjekteier er prosjektets øverste leder (Difi) og er linjeorganisasjonens representant i prosjektet. Prosjekteier eier faseovergangene i en prosjektmodell. Dette omfatter beslutningspunktene PB3-A, PB3-B og PB4. Prosjekteier for hver av kontraktspartene må selvstendig godkjenne beslutningspunktene innenfor sitt kontraktansvar. Prosjekteier hos virksomheten (eier av virksomhetsbehovet X1) har en særrolle og er i Prince-2 definert som prosjektsikring. Dette omfatter å sikre at løsningen som utvikles ivaretar virksomhetsbehovet, og føringer og krav fra virksomheten. De operative nivåene L3 Prosjektleder Prosjektleder utfører den daglige ledelsen av et prosjekt. Avklare rammer, utvikle planer, hente inn ressurser, organisere arbeidene, innhente beslutninger og rapportere. L4 Leder for produksjon Leder for produksjon kan være prosjekteringsleder, anleggsleder, mv. L5 Leder for fagdisiplin Denne rollen innen prosjektering vil være leder for fagfeltene arkitektur, RIB, VVS, rør, elektro, osv. Innenfor produksjon og montasje vil dette være formenn innen de ulike fagdisipliner. L6 Gruppeleder Gruppeleder innen prosjektering er en som leder en gruppe prosjekterende. Tilsvarende i produksjon og montasje ute på byggeplass, vil dette være bas. L7 Fagarbeider Dette omfatter arkitekter, rådgivere og fagarbeidere for produksjon og montasje. Tett knyttet til beslutninger Disse åtte organisasjonsnivåene går igjen i alle prosjekter. I mindre prosjekter vil man normalt kunne slå sammen nivåer, i større prosjekter kan det være aktuelt å splitte nivåer. Et eksempel der man splitter, vil være inndeling av prosjekt i underprosjekter med underprosjektledere. Med definerte organisasjonsnivåer blir det tydelig hvem som skal delta i kommunikasjonen. Dette slanker møter, reduserer timeforbruk, forenkler, effektiviserer kommunikasjonen og gir normalt et forbedret prosjektresultat. Det gir også en organisasjon med økt handlingskraft. Knytter vi organisasjonsnivåer sammen med beslutninger får vi en beslutningsmatrise som tydeliggjør beslutninger og plasserer beslutningsansvaret i et prosjektforløp. Organisasjonsnivåer og beslutninger er satt sammen i matrisen Beslutninger X12. Du kan lese mer om denne i saken: Codex X12 - hvor ofte ender byggeiere opp med feil bygg? Beslutninger i en prosjektmodell. (lenke) I neste kapittel i av prosjektmodellen Codex X-12 vil vi se nærmere på hvordan man organiserer kompetanse i en prosjektmodell. LES OGSÅ: Codex X12 - Kostnadssprekk og konflikter skyldes ofte utydelig definerte prosjekter – Fasene i en prosjektmodell Codex X12 - Helheten i en prosjektmodell Codex X12 - Samfunnet vil spare milliarder med riktig prosjektmodell Artikler og figurer er samlet på nettsiden CodexX12.no.

Hvilke byggeiere vil vinne fremtidens utleiemarked? Her må rådgivermiljøer og entreprenørene følge med i timen! Kompetanse i en prosjektmodell. Bygger mange byggeiere en kopi av de byggene de har bygd tidligere, bare litt forbedret? Har de kjørt seg fast i fortiden og tradisjonell tenking rundt tilførsel av kompetanse - i stedet for å utfordre og utvikle bygg som svarer på fremtidens brukerbehov? Svaret er ofte ja og det fører til at mange bygg får redusert attraktivitet og kortere levetid, før en total ombygging er nødvendig. Hvilke kompetanser som tas inn i et byggeprosjekt har stor innvirkning på prosesser og hvilket produkt som utvikles. Kompetansesammensettingen er derfor en kritisk faktor for å sikre gode prosjektresultater både for eier og brukere - for økonomi og ikke minst for bærekraft. I prosjektmodellen Codex X12 er det utviklet og definert en kompetansematrise som angir hva slags kompetanse som skal tas inn i prosjektet, på hvilke tidspunkt. Mangel på kompetansestruktur I mange prosjekter tilføres en generalisert kompetanse inn mot hele tidligfasen. Det fører til at kompetansepersoner som er nødvendig i noen utredninger, også følger med inn i andre utredninger - der de har lite å tilføre. De blir rådgivende tilhørere eller synsere utenfor sitt kompetanseområde. En slik generalisering fører til at man utnytter kompetanse dårlig. Den fører også til at spisset kompetanse inn mot enkelte utredninger, uteblir. Med etablering av nye samspillkontrakter har flere tatt til orde for å bringe mer kompetanse, for eksempel leverandører, tidligere inn i prosjektforløpet. Tilføring av mer kompetanse er positivt, men å tilføre et større volum av aktører kan være ødeleggende for gode prosesser og gi et negativt resultat. Det er derfor nødvendig å strukturere tilføring av kompetanseaktører inn i prosjektene. Kompetansematrisen Nedenfor er det satt opp en oversikt over den kompetansen som tilføres inn mot hver fase i prosjektet. Med en slik matrise tilføres den kompetansen man forventer tilfører en verdi i de ulike prosjektfasene. Tilsvarende avgrenser matrisen at aktører med irrelevant kompetanse, deltar. En kompetansematrise kan utvikles inn mot prosjektfaser eller rettes inn mot hver enkelt aktivitet/utviklingsgruppe i den enkelte fasen (Taskteams ISO 19650). Nedenfor er Prosjektmodellen Codex X12 brukt for å definere en kompetansesammensetting inn mot de ulike prosjektfasene. Den innledende delen Den delen som leder frem til prosjektet har tre faser (X1-X3). X1 Utløsende behov Kompetanse behovet i første fase er rettet mot utvikling av virksomheten og kan omfatte strategier, markedsplaner, oppdatering av infrastruktur og frem til definering av et virksomhetsbehov. Dette er i første rekke bedriftsinterne kompetanser, men der man kan supplere med eksterne tilleggskompetanse. X2 Konsept I denne fasen skal man finne frem til konsepter for å svare ut et virksomhetsbehov. Her vil det være ulike kompetansebehov innenfor de forskjellige konseptene som skal defineres og analyseres. Dette kan omfatte kompetanse innen bedriftens forretningsområde, outsourcing, virksomhetsarkitektur, mv., men også inn mot helhetsløsning for bygg med investerings- og årskostnad, risiko og usikkerhet. X3 Bestilling Denne fasen definerer selve bestillingen av prosjektet. Kompetansebehovet rettes mot å definere rammer og føringer for prosjektet. Dette kan omfatte krav til investering- og årskostnad, tid, definering av virksomhetsbehov og viksomhetskritiske faktorer, krav og rammer til bygg, bærekraft, mv. Det vil også omfatte virksomhetsmål, krav til gevinster og strategi for gjennomføring. Tidligfase prosjekt Også kalt forprosjektet, har fem faser (X4-X8). X4 Designbasis I denne fasen skal krav fra virksomhet og bruker omsettes til krav til et bygg eller mer presist; til en designbasis som definerer alle forutsetninger for funksjonalitet og utforming av bygget. Kompetanse inn mot optimalisering av virksomhetsarkitektur og tjenestedesign er sentralt. Arkitekt og rådgivere innen teknikk bygg og digitalisering/industrialisering er sentrale for å definere designbasis på overordnet nivå. Leverandører er aktuelle for å definere muligheter som nye produkter og teknologier gir. X5 Arkitektur - Mulighetsstudie & Alternativanalyse Denne fasen er en mulighetsstudie for å finne frem til riktig arkitektur. Her er arkitekten sentral sammen med kompetanse for å optimalisere viksomhetsfunksjoner. RIB (rådgivende ingeniør byggeteknikk) for å sjekke at aktuelle løsninger er mulig å bygge. Tekniske fag er inne for å avklare føringsveier og plassbehov. Byggentreprenøren kan tas inn som rådgiver for å avdekke kostnadsdrivende løsninger. Fasens andre del er en alternativanalyse der kompetanser som kalkulasjon og årskostnad, risiko og usikkerhetsanalyse, og analyse inn mot forutsetning for funksjonalitet, er sentrale kompetanseområder. X6 Hovedarkitektur Denne fasen definerer hovedarkitekturen for bygget med volumer og flater, fasader, uttrykk, uteområder mv. Arkitekt (bygg og landskap) er den mest sentrale kompetansen. RIB er inne for å avklare konstruksjonen. Tekniske rådgivere er med for å definere føringsveier og plassbehov for tekniske anlegg. Byggentreprenøren vil her kunne være en sentral kompetanse for å optimalisere løsninger for produksjon. Fasens andre deler omfatter kompetanse for kalkulasjon og risikoanalyse, og for å etablere kostnads- og styringsramme. X7 Funksjoner - Krav til funksjon Denne fasen definerer alle funksjoner i bygget. Det er her behov for teknisk kompetanse inn mot klima/luft, varme, lys, skallsikring, dørmiljø og andre brukerfunksjoner. Denne kompetansen kan hentes inn gjennom rådgivere og leverandører. X8 Funksjoner - Valg av løsning Denne fasen omhandler valg av løsninger/produkt for å tilfredsstille funksjonskrav (fra X7). I denne fasen er leverandør- og entreprenørkompetanse mest sentral. Rådgiverkompetansen kan delta gjennomgående eller legges inn som en kontrollfunksjon mot slutten av aktivitetene eller i slutten av fasen. Produksjonsfasen Produksjonsfasen har tre faser (X9-X11). X9 Produksjonsunderlag I denne fasen skal produksjonsunderlaget produseres. Dette har tradisjonelt vært tegninger fra arkitekt og rådgiver. Med en industrialisering i bransjen vil denne fasen bestå i å modellere underlag for en automatisert produksjon. Dette vil føre til at leverandør- og produsentkompetansen blir mer sentral i denne fasen. X10 Produksjon bygg Denne fasen omhandler selve produksjonen av bygget. I dag består dette i hovedsak av produksjonskompetanse med bruk av håndverkere. Her vil bransjen få et skifte fra produksjon på byggeplass til at produksjonen foregår hos produktleverandører. På byggeplassen vil man få et skifte fra produksjon til montasje. Dette vil endre kompetansebehovet fra håndverkere til montører. X11 Produksjon - Idriftsetting bygg Denne fasen består i dag mye av tekniske kompetanse for innregulering og igangkjøring av komponenter. Frem i tid vil dette i større grad bli overtatt av digitale løsninger og AI. Fasen vil avdekke og utbedre feil på produkt og montasje der kompetansebehovet vil variere ut fra produkt. Driftsfasen X12 Garanti - Gevinstrealisering Denne fasen omhandler garantiperioden med leverandørkompetanse avhengig av aktuelle funksjonsfeil. Fasen omhandler også gevinstrealisering. Kompetansebehovet er avhengig av hvilke gevinster som skal realiseres. Kompetanse for å hente ut gevinster kan omfatte digitale løsninger, nye verktøy, organisering og optimalisering av nye prosesser. Kompetansebehovet er i rask endring Nye bygg blir stadig mer teknisk kompliserte. Det medfører at det er behov for mer kompetanse og ikke minst mer spesialkompetanse ved utvikling av bygg. Aktører som klarer å markedsføre seg med spissere bruk av kompetanse, vil vinne frem. Det er disse som sammen med byggeier vil kunne sette opp bygg som tar høyde for utviklingen i fremtiden. Kompetanse har fått kortere levetid før ny teknologi og nye løsninger overtar. Det er derfor mer krevende å holde seg oppdatert enn tidligere. Dermed vil de som er nærmest utvikling av ny teknologi, bli de som blir tatt inn for å tilføre kompetanse. Leverandørkompetanse blir i flere tilfeller å foretrekke fremfor rådgiverkompetanse, et scenario som var lite aktuelt om vi går litt tilbake i tid. Den raske utviklingen medfører at det som var riktig kompetansesammensetting på et bygg for to år siden, ikke nødvendigvis er riktig for et nytt bygg som skal påbegynnes nå. Den hurtige teknologiutviklingen medfører at en strukturert kompetansematrise er viktigere enn noen gang, for å oppnå ett riktig bygg! I neste artikkel, som kommer til høsten, tar vi for oss samspillsmodeller mellom kontraktspartene – i all hovedsak byggherre og entreprenør. Les flere artikler om prosjektmodellen Codex X12: Innlegg: Codex X-12 - En utydelig organisering av byggeprosjekter er som å be om økte kostnader og et dårligere produkt – Organisasjonsnivåer i en prosjektmodell. Innlegg: Codex X12 - hvor ofte ender byggeiere opp med feil bygg? Beslutninger i en prosjektmodell. Innlegg: Codex X12 - Kostnadssprekk og konflikter skyldes ofte utydelig definerte prosjekter - De viktige fasene i en prosjektmodell Innlegg: Codex X12 - helheten i en prosjektmodell - Samfunnet vil spare milliarder med riktig prosjektmodell