For at et prosjekt skal kunne krones som en suksess skal så mye klaffe. Rett prosjekt, leveranse til tiden, innenfor budsjettet og til rett kvalitet. Men om sluttproduktet ikke oppfyller de behovene prosjektet ble planlagt for, kan man uansett ikke sprette champagnen. Her kan du lese om hva som skjedde da brukerbehovene og involvering forsvant et sted på veien, og hvordan du kan unngå å gjøre det samme.
Dette er andre del av vår føljetong om erfaringer fra Stranger-prosjekter, hvor prosjektet er stort, komplekst og passer dårlig med virksomhetens prosjektmodell og kompetanse. Les mer om Stranger-prosjekter her.
Prosjektet startet godt. Det ble gjennomført en strukturert og grundig prosess for å samle inn brukerbehovene, så vel som for kontraktstrategi, konsept og utvelgelse av personell. Etter den gode starten på prosjektet kom man ut av konseptfasen med et prosjekt som ville oppfylle brukerbehovene. Når prosjektet nærmet seg ferdigstillelse viste det seg likevel at brukerbehovene hadde glippet underveis i prosessen. Hvorfor ble det slik, hvilke konsekvenser fikk det og hvordan kan man unngå det?
Dette må du huske når du bytter prosjektressurser
Da virksomheten underveis i prosjektet byttet ut flere sentrale ressurser i prosjektet, ble det første skritt på veien mot at viktige tekniske behov og informasjon fra brukerne forsvant.
Valget om å bytte ut prosjektressurser må slett ikke være unaturlig eller et sykdomstegn. Det kan handle om at ulik kompetanse trengs i ulike faser. Eller det gjøres fordi man oppdager at det er valgt feil ressurser ut fra personlige karakteristika eller kompetanse. Et ressursbytte kan uansett årsak gi komplikasjoner.
Unngå «not invented here»-syndromet
Det er viktig å huske på at ressursene som har vært inne før deg gjerne også har gjort gode avveiinger og avklaringer, og man bør ha gode grunner for å starte helt på nytt.
Vi observerer at det ikke er uvanlig at nye ressurser får et innslag av «Not invented here»-syndromet. Det handler om at man opplever at det man selv bestemmer eller finner på er bedre enn hva andre klarer, uavhengig av om det faktisk er sant. Som resultat kan man kaste ut gode avgjørelser sammen med de som kanskje burde byttes ut. I disse situasjonene er det prosjektleders ansvar å utøve ledelse, god struktur og helhetstankegang. Sjekk at du ikke går tilbake på avgjørelser som faktisk hadde mye for seg. På denne måten kan man sørge for at man ikke kaster barnet ut med badevannet.
Hvor mye involvering er nok?
I henhold til beste praksis involverte virksomheten i dette prosjektet sine brukere tidlig og godt på utvalgte temaer, og lukket deretter åpningen for innspill. Denne prosessen er likevel avhengig av at man sørger for at involveringen og innspillene faktisk materialiserer seg i prosjektet.
I dette prosjektet ble brukerne/leietakerne holdt på armlengdes avstand i optimaliseringsfasen, og man så bort fra enkelte avgjørelser som ble tatt tidlig i prosessen. Det er ikke er nok å hente inn og dokumentere tekniske krav fra brukerne. Man må innlemme dem i planverket og følger opp at det ivaretas i praksis – og når noe skal kuttes ut må man sjekke innom denne dokumentasjonen for å sikre at man er på vei til å ta et godt valg.
En god brukerkoordinator kan også være riktig et ledd mellom prosjektet og brukerne, og fungere som en «oversetter» mellom prosjektet og virksomheten der det er et behov.
Premissene eies av virksomheten og brukerne
Prosjekteier skal legge frem premissene og brukerbehovene i prosjektet, og følge opp at de blir ivaretatt. Prosjektleders ansvar er å oppfylle valgene innenfor rammene – tid, kostnad og kvalitet. Å sette ut ansvaret for deler av premissgiving til den som skal gjennomføre dem kan være uheldig, og påvirker ivaretakelsen av brukerbehovene. Likevel var det nettopp det som skjedde i dette prosjektet.
Premisser bør altså komme fra virksomheten, representert av prosjekteier og brukerne som er involvert. Det er disse som vet hva som vil gi linjeorganisasjonen mest verdi til slutt. Bestiller var uerfaren og «delegerte» deler av premissgivning til prosjektleder. Dette medførte økt avstand mellom prosjekt og virksomhet. Det er heller ikke riktig overfor prosjektleder å stilles til ansvar for denne viktige oppgaven.
I stedet for dette valget kunne man eksempelvis brukt styringsgruppen for å støtte prosjektet der prosjekteier følte den ikke strakk til.
Rett kompetanse er helt essensielt
Det er flere typer kompetanse som må til for sikre at brukerbehovene ivaretas.
Det må begynne med en tydelighet fra bestiller på hva prosjektet skal løse, og at prosjekteier har lagt opp en struktur som gjør at brukerperspektivet blir sikret - sammen med leverandør- og prosjektperspektivene. Deretter må man ha fagkompetanse i prosjektet, evne til å forstå brukernes behov og, vi tør påstå, en «oversetterkompetanse».
Dersom brukerne ikke er byggeteknisk kompetente vil de ikke automatisk forstå prosjektering, prosessene og hva som skjer i byggeprosjekt. Da må noen ha i oppgave å «oversette» brukernes behov til tekniske krav, og likeledes oversette tekniske forklaringer til budskap brukerne forstår. Dette er typisk oppgaven til brukerkoordinatoren. Gjennom «oversettelser» kan brukerkoordinatoren sørge for at man ikke mister viktige premisser for brukerne, samt at man minnes på disse underveis i prosjektet. Eksempelvis er det vanlig å ha en dedikert person til denne rollen i sykehusprosjekter, mellom helsepersonell og byggeteknisk personell.
Hvis det er svært stort gap mellom teknisk kompetanse hos brukerne og i prosjektet eller der hvor brukerbehovene er helt kritiske for å lykkes med å nå prosjektmålene kan det også være lurt å ha en brukerkoordinator "på hver side av bordet", i mottaksprosjektet og i byggeprosjektet. Husk bare på at man ikke sitter på to ulike sider, men i samme båt.
Hvordan sikrer jeg at brukerbehovene ikke glipper?
I dette prosjektet gjorde alle disse faktorene under ett til at man oppdaget, litt for sent, at flere viktige premisser fra brukerne ikke var oppfylt i sluttproduktet. Omgjøring tar alltid med seg en kostnad, og ligger ikke i budsjettet. Konsekvensen av å glippe på brukerbehovene kan altså bli alvorlige.
Det er lett å tenke at akkurat denne kombinasjonen ikke ville skjedd i et prosjekt en selv er involvert i, men man kunne fått samme resultat gjennom et annet hendelsesforløp. Det viktige å ta med seg er at en bør sikre prosesser for å samle inn brukerbehovene, dokumenterer, inkorporerer det i planverket og følger opp underveis. Det bør være en definert periode for innspill, det er ikke god praksis å ikke hente inn «nye» brukerbehov gjennom hele prosjektet. Samtidig kan man ikke bare samle inn behovene og deretter holde brukerne på armlengdes avstand frem til prosjektet leveres.
En dyktig brukerkoordinator kan fungere som en «oversetter» mellom byggeprosjektet på en side og brukerne/mottaksprosjektet på den andre.
Noen tips til sist:
- Dokumentasjon bør skje kontinuerlig, og på en måte som gjør det lett for andre og sette seg inn i arbeidet. Dersom informasjonen bare «tas over bordet» bør man ta til orde for at informasjon som samles inn struktureres og lagres på en grundig, ryddig og tilgjengelig måte. Et enkelt IT-verktøy kan være til god hjelp.
- Å samle inn brukerbehov hjelper ikke dersom de ikke planlegges inn og gjennomføres i prosjektet.
- Bytter du ut prosjektressurser må du ha god dokumentasjon de nye ressursene kan gå tilbake i, og samtidig ha et øye på hvorvidt og hvordan kontinuiteten i prosjektet er mulig å ivareta.
- En dyktig brukerkoordinator har ett hovedfokus; å ivareta brukernes interesser, innenfor de rammene som er lagt. Noen må få og ta brukerkoordinatoransvaret.
- En god brukerkoordinator er en god «oversetter», eller to-språklig, om du vil.
- Kutt og endringer skal forekomme i optimaliseringsfasen, men man må sikre at man tar avgjørelsene med bakgrunn i rammene og brukerbehovene.
