Egde har nylig hatt tre utviklere inne på Skatteetatens prosjekt kompensasjonsordningen.no. Portalen ble lansert 18. april, etter tre hektiske uker – som også inkluderte påske. Totalt var rundt 70 personer involvert i prosjektet. Det var med andre ord mye som skulle klaffe på kort tid.

I etterkant av et prosjekt er det alltid lærerikt å ta en gjennomgang for å se på hva som fungerte. I denne artikkelen deler vi fem suksessfaktorer med overføringsverdi til andre prosjekter.

1. Man startet med en definert prosess, men overlot detaljene til prosjektet

Flyten var definert da prosjektet startet. Noen skulle søke kompensasjon, det skulle være et sett regler for å bestemme om søker ville få innvilget, og dette skulle inn i et sakssystem. Dette er viktig, siden IT-systemer skal støtte opp om en prosess. Har man ikke klart for seg prosessen systemet skal støtte, blir det problemer.

Den overordnede prosessen var med andre ord klar. Samtidig var ikke detaljene på plass. Prosjektet fikk jobbe med detaljene og unngikk å bli fanget av uhensiktsmessige spesifikasjoner.

2. Organisasjonen støttet opp om prosjektet

Prosjekter er ofte avhengig av funksjoner utenfor prosjektet, for eksempel for å få tilganger til systemer eller data. Manglende tilganger kan fort forsinke et prosjekt. Her sørget organisasjonen for å levere nødvendige tjenester til rimelig tid. Prosjektet kunne slik jobbe effektivt og holde seg på plan. Der det var nødvendig med avklaringer, for eksempel av teknisk art, fikk prosjektet mulighet til å gjøre avklaringene raskt.

Både organisasjonen og prosjektdeltakerne forstod hvorfor dette var et nyttig prosjekt. I dette prosjektet var det ytre påvirkning som bidro til motivasjonen for å levere et godt prosjekt: Det var et viktig prosjekt. Det er langt fra alltid tilfelle. Da må man jobbe ekstra med å få frem nytten av prosjektet. Viser det seg derimot vanskelig å formidle hvorfor et prosjekt er nyttig for organisasjonen og prosjektdeltakerne, bør man vurdere om man prosjektet er riktig i sin foreslåtte form – eller riktig i det hele tatt.

3. Prosjektgruppen kjente bedriftskulturen, hadde riktig kompetanse – og antall

Deltakerne i prosjektet var sammensatt på en slik måte at da prosjektet startet, var det enkelt å fordele oppgaver. Da har man truffet med sammensetningen av kompetanse. Dersom man har problemer med å se hvilke oppgaver bestemte personer kan fylle, kan det tyde på at prosjektgruppen ikke er riktig sammensatt.

Å levere et prosjekt på tid, kost og kvalitet handler ikke om å ha «flere» deltakere. Det må være riktig antall deltakere. Det vil ikke alltid være gunstig for å prosjektet å legge til flere deltakere. Får deltakerne nok å gjøre, for lite, eller for mye? I dette prosjektet mener vi man traff godt med antallet deltakere.

Et tredje aspekt var at deltakerne allerede var godt kjent med bedriftskulturen. Når man vet hvordan ting fungerer i en organisasjon er det klart at en del ting går raskere. Prosesser, rutiner og beskrivelser er én del, men kjennskap til kulturen skal ikke undervurderes. Det er selvfølgelig ikke mulig i alle prosjekter. Har man prosjektdeltakere som kommer inn utenfra, må man sette av tid til innrullering. Man må gi dem best mulig forutsetninger for å sette seg inn i hvordan organisasjonen fungerer.

4. Utviklerne fikk bruke tilstrekkelig tid på prosjektet

Tilstrekkelig tid ble satt av til dette prosjektet. Man unngikk å ha mange prosjektdeltakere med små stillingsbrøker. Jo mer man kan fokusere tiden sin, dess mindre tid går med til å holde seg oppdatert på mange prosjekter. Dermed kan man bruke mer tid på sine oppgaver. Som kjent tar det tid og energi å bytte mellom oppgaver. Denne friksjonen ble minimert.

Å ha en rolle som bindeledd mellom interessentene og utviklerne i prosjektet fungerte bra. I den rollen finnes personer som kan nok om både utvikling og brukerbehov til å kunne snakke med begge. Utviklerne fikk bruke tid på utvikling og løsningsdesign, mens rollen, som gjerne omtales som funksjonell konsulent, tok diskusjonene.

5. Det ble kjørt demonstrasjoner allerede første uken – og ofte

At man gjennomfører demonstrasjoner tidlig – og ofte – har flere gunstige effekter. Det gir ekstra motivasjon til prosjektet for å levere. Minst like viktig er at demonstrasjoner fungerer som forventningsavklaring for interessentene. Alle parter får innsikt i hvordan prosjektet skrider frem og hva som leveres. For et prosjekt med kort horisont, som dette, kan ukentlige demonstrasjoner være bra. I andre prosjekt og organisasjoner kan også annenhver uke eller månedlig være en god frekvens. Dette må tilpasses til organisasjonen.

Demonstrasjoner er også en mulighet til å få testet ut idéer tidlig. Mange krav i et prosjekt kan løses på flere måter. Det er billigere å finne ut tidlig at noe ikke fungerer, heller enn sent. Utviklerne får testet løsningene, mens interessentene får komme med tilbakemeldinger.

Oppsummering

I denne artikkelen har vi trukket frem fem årsaker vi mener bidro til at prosjektet ble vellykket: prosessen man skulle støtte var definert, organisasjonen støttet prosjektet, prosjektgruppen var riktig sammensatt, deltakere fikk bruke nok tid og demonstrasjoner kom raskt i gang.

Å sette opp et prosjekt riktig og sørge for at det gjennomføres på en god måte avgjør om det blir suksessrikt eller ikke. Egde besitter prosjektledere med stor bredde i erfaring og bakgrunn. Vi har prosjektledere med mange års erfaring fra flere forskjellige sektorer. Egde investerer i sine ansattes videreutvikling, slik at mange er sertifisert i PRINCE2 på Practitioner-nivå. Trenger din organisasjon prosjektleder med gjennomføringskraft? Har organisasjonen et prosjekt som må planlegges og settes opp på riktig måte? Ta kontakt for en hyggelig prat.