Prosjekt meg her og prosjekt meg der

Rundt it-avdelinger kryr det av prosjekter. Sikkert over halvparten av dem burde hete noe annet. Jeg foreslår "styrt arbeid".

Publisert Sist oppdatert

Nylig har to it-avdelinger fortalt meg, uavhengig av hverandre, at de har femti prosjekter på gang. Avdelingene er middels store, 15-25 medarbeidere. Det er noe her som ikke stemmer. Det er ikke trolig at så få mennesker er i stand til å drive og følge opp femti prosjekter ved siden av det løpende arbeidet. Forsøker de det, vil de fleste prosjektene ligge i dvale. Antagelig vil ingen av dem, selv ikke de viktigste, ha fremdrift fordi ressursene blir smurt ut for tynt. Når er et prosjekt et prosjekt?

Den vanligste definisjon på et prosjekt er arbeid som blir organisert for å realisere et definert sluttresultat og som dessuten har en begynnelse og en slutt. Når sluttresultatet er levert, skal prosjektet avsluttes. Problemet med denne definisjonen er at det meste it-avdelinger gjør kan kalles prosjekter.

Gjør det noe at vi kaller alt for prosjekter? Ja, fordi et velorganisert prosjekt forutsetter betydelig overhead i form av prosjektledelse, styringsgruppe, rolledeling, rapportering, budsjett, kickoff og så videre. Typisk utgjør denne overhead mellom fem og 15 prosent av ressursforbruket. Vi bør spare oss selv for denne overhead der vi kan.

Her kommer mitt poeng: Vi bør forbeholde begrepet prosjekt til arbeid der det er erkjent en tydelig risiko. Den kan være forretningsmessig eller teknisk. Det er denne risikoen, denne bekymringen, som skal holdes under kontroll gjennom god prosjektledelse, aktiv styringsgruppe osv. Er vi helt trygge på det vi skal gjøre, vet hvordan det skal gjøres og hvem som skal gjøre det, er det ingen grunn til å etablere et prosjekt.

Nøkkelspørsmålet er om vi bedømmer gjennomføringsrisikoen som stor eller liten. Er den stor, blir neste spørsmålet: Kan vi regne med mange endringer mens arbeidet pågår? Hvis kravene og forholdene er ustabile, er svaret å organisere et smidig prosjekt. Er forholdene rimelig stabile, kan et tradisjonelt prosjekt duge. Hvis gjennomføringsrisikoen er liten, blir spørsmålet: Har vi behov for å organisere et team og utpeke en prosjektleder? Er svaret ja, snakker vi om styrt arbeid. Er svaret nei, kan arbeidet gjennomføres "i linjen". Simsalabim – antall prosjekter er halvert. (Tenk så glad direktørene som slipper å sitte i alle styringsgrupper blir.)

En viktig hensikt med å organisere arbeidet i prosjekter er synlighet. De skal synes i landskapet. De skal presenteres for beslutningsfatterne med definerte mål, omfang, kostnadsramme og fremdriftsplan. Den iboende risikoen skal konkretiseres. Bare da kan de vurdere om de skal investere i dette prosjektet. Prosjekter skal ikke sige i gang "under radaren"; å starte dem skal være en synlig, villet handling. Å stoppe dem hvis ting ikke utvikler seg som de skal, skal også være en villet handling.

Prosjekter skal ikke være for små, men de skal heller ikke være for store. Da blir det vanskelig å holde dem på sporet. Ofte er det bedre å definere et knippe prosjekter som henger sammen, men som foregår forskjøvet i tid. Knippet pleier å kalles et program. Fordelen med at programmet ledes av én person er at ressurser kan disponeres som ett hele. Får et av prosjektene problemer, kan de få overført ressurser fra et annet i knippet.

Organisasjoner, akkurat som folk, modnes langsomt. Det går an å tenke på modning som en trapp med 5-6 trinn. Trinnene kan hete: Forvirret, Funker, Alt på stell, Bidrar, Differensierer, Omskaper. På de tre nederste trinn gjør it-avdelingen det de er bedt om, mer eller mindre bra. På de tre øverste trinn har IT fått økende konkurransemessig betydning.

Det er flere kjennetegn på hvor langt modningen er kommet i en it-avdeling. En av dem er hvor bevisst den er på å starte og styre utviklingsprosjekter. Ett er sikkert: En avdeling som baler med femti prosjekter er kommet kort i modningen. Den står sannsynligvis på nest nederste trinn: Avdelingen jobber hardt og har kanskje leveranser til å leve med, men servicegraden og kvaliteten er ujevn. Løfter blir ofte brutt. Kundene, dvs forretningsenhetene, stoler ikke på at de får levert det de har bruk for. Derfor prøver de å finne måter å omgå it-avdelingen på. Det blir slit for alle.

hidas@online.no