Falske prosjekter

Nylig har to it-avdelinger fortalt meg, uavhengig av hverandre, at de har omtrent femti prosjekter på gang. Avdelingene er middels store, 15-25 medarbeidere.

Det er noe her som ikke stemmer. Så få mennesker er ikke 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 å gjennomføre en definert endring og som dessuten har en begynnelse og en slutt. Når endringen er i havn, skal prosjektet avsluttes. Ideelt sett skal det ikke skli over i drift selv om det skjer altfor ofte. Det er alltid et sykdomstegn.

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 en viss styring i form av prosjektledelse, styringsgruppe, rolledeling, rapportering, budsjett, kickoff osv. Typisk utgjør denne overhead mellom 5 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, typen NAV. 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, sekvensielt 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 som vanlig, det vil si ”i linjen”. Simsalabim – antall prosjekter er halvert. (Tenk så glad direktørene blir som slipper å sitte i alle styringsgruppene.)

En viktig hensikt med å organisere arbeidet i prosjekter er synlighet. De skal synes i landskapet fordi det å jobbe i prosjekt sjelden er karrierefremmende. Skal flinke folk likevel ta sjansen, må det være en oppside. Prosjektene  skal presenteres for beslutningsfatterne med definerte mål, omfang, kostnadsramme og fremdriftsplan. Den iboende risikoen skal konkretiseres. Bare da kan lederne vurdere om de vil investere i dette prosjektet fremfor andre. 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 (kfr. NAV).

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 samlet. Får et av prosjektene problemer, kan de få ressurser fra et annet i knippet.

Organisasjoner, akkurat som folk, modnes langsomt. Det går an å tenke på modning som en trapp med seks 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 økt selvstendighet og 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 slitsomt for alle.

hidas@online.no