
25. januar 
2008               
Utskriftversjon 
pdf                 
Til hovedsiden
Forskningsledelse:
Lede prosjekt
Klar til start
Du har 
fått ansvar for å starte opp og gjennomføre et prosjekt i anvendt forskning. Vi 
forutsetter at det foreligger en gjennomarbeidet målsetning for prosjektet, det 
vil si av den nytteverdien som skal realiseres, og som er begrunnelsen for 
prosjektet. Vi skal senere, under Lede organisasjon, se hva som må til for at 
denne avgjørende viktige forutsetningen skal være oppfylt. Men her tar vi den 
altså for gitt.
        I praksis vil oppgaven selvsagt være 
svært avhengig av størrelsen og varigheten av prosjektet. Her tenker jeg meg et 
prosjekt med kanskje 10-15 medarbeidere og 2-4 års varighet. Ikke alt som 
omtales vil være relevant i et meget mindre prosjekt, men resonnementene er 
ganske robuste for oppskalering. Prosjektets karakter, om det f.eks. gjelder 
utvikling av materiell og/eller programvare, om det er en kvantitativ analyse 
eller en studie, er ikke avgjørende for de kvalitative forholdene vi skal se på, 
så lenge det dreier seg om prosjektmål i rammen av et systemkonsept, se
Innledning.
Begrense 
ambisjonsnivået
Prosjektets overordnede målsetning, dvs. på konseptplanet, er altså gitt. På 
systemnivået under, de detaljerte funksjonelle kravene, vil det allikevel oftest 
være spillerom med hensyn til ambisjonsnivået. Her gjelder det å begrense seg, 
ikke å vise hvor mange gode idéer man har. I innovative prosjekter er det alltid 
grunner til at det kan oppstå budsjettoverskridelser og forsinkelser, så det 
gjelder å holde risikoen så lav som mulig. Legg prosjektet på det laveste 
ambisjonsnivå som realiserer den avgjørende del av målsetningen. Når 
prosjektet er vellykket gjennomført, vil det oftest være grunnlag for å følge 
opp med tilleggsfunksjoner og videreutvikling i et eller flere senere 
prosjekter. Ta med Piet Heins "Arbejds-trick" som huskevers for dette meget 
viktige momentet:
 
| 
		 
  | 
		
		 
		
		Du skal bruge en del  | 
		
		 
		
		Når du først  | 
	
Og "lagt 
seletøj på den" har du ikke gjort før nytteverdien av prosjektet er godtgjort.
        Selv om du klarer å begrense kravene 
fra starten, vil det ofte oppstå press for å utvide dem underveis. Etter hvert 
som arbeidet går fremover vil det dukke opp nye idéer og fristende muligheter, 
eller brukere/markedsfolk rapporterer flere ønsker. Da gjelder det å være meget 
kritisk. Muligheter som forenkler prosjektet, f.eks. pga ny teknologi, kan gå 
hvis det er noenlunde risikofritt. Men ikke ellers. Press fra brukersiden kan 
være velbegrunnet, men ikke si ja før virkningen for konseptet og 
gjennomføringen er klarlagt. Endringer som bare angår en "lokal" funksjon på et 
lavt systemnivå er mindre risikable enn endringer som påvirker spesifikasjonene 
for flere delsystemer. Under enhver omstendighet må du unngå at prosjektet får 
karakter av skyting mot bevegelige mål. Ustabile prosjektmål er en sikker vei 
til nederlag. IKT-prosjekter er spesielt utsatte for denne faren. Teknologien er 
jo "så fleksibel", må vite.
Strukturere 
prosjektet – "systemtrekanten"
Du 
starter med å utarbeide en plan for gjennomføringen av prosjektet. Denne planen 
vil være grunnlaget for formell godkjennelse av prosjektet, så de rammene som 
blir lagt i den kan det være slitsomt å endre på senere. Organisasjonen har 
skjemaer for prosjektplaner, ofte ganske detaljerte, for spesifisering av 
nødvendig innsats, pengeforbruk, fremdrift, oppdeling i delprosjekter, osv. Ikke 
begynn med frihåndsarbeid i disse skjemaene før du har strukturert og analysert 
prosjektet i "systemtrekanten".
| 
		 
 
 System-trekanten  | 
		
		 
 
  | 
	
Trekanten 
er en meget enkel, men nyttig modell som vi skal referere til i flere 
sammenhenger. Trekantens øverste nivå er – naturligvis – systemkonseptet. 
Det er beskrivelsen av formålet med prosjektet og hovedtrekkene i løsningen. Det 
midterste nivået er de funksjonelle krav til systemet, og i grove trekk 
metodegrunnlaget for å møte disse kravene. Det nederste systemnivået er 
spesifikasjonene for de enkelte delene av systemet, og oppgavene for å realisere 
disse delene. I et stort prosjekt kan dette nivået være delt i flere 
undernivåer.
        
Trekanten 
er altså en modell for strukturering av prosjektet. Benytt denne strukturen også 
når du presenterer prosjektet. Da unngår du at f.eks. fremdriftsmøtene blir 
dominert av dine egne aksjonslister, - de vil bare forvirre og kjede tilhørerne. 
Hold i stedet fokus på formålet, konseptet og hovedaktivitetene som skal 
realisere det, og bruk tid på de kritiske leddene. En slik fremstilling gir deg 
tillit hos de som har mindre innsikt i prosjektet enn du selv har, og det 
gjelder jo alle tilhørerne.
        Vi skal nå se nærmere på 
utfordringene knyttet til de ulike systemnivåene. I denne gjennomgangen skiller 
vi ikke mellom planleggingen forut for prosjektgodkjennelsen, og 
prosjektgjennomføringen. Det dreier seg om en kontinuerlig prosess som på et 
visst stadium gir et tilstrekkelig grunnlag for en formell prosjektplan med 
ressursbehov, tidsplan, organisering, osv. Men som vi skal se, plangrunnlaget må 
følges opp gjennom hele prosjektet.
       
Konseptet er 
avgjørende
Vi må tilbake til Kant igjen: Jeg forstår ved et system en samling av mange 
slags viten under en idé. Den samlende idéen, konseptet, er prosjektets 
bærende element, reisverket. Det fastlegger i hovedtrekk hvordan prosjektets mål 
skal realiseres. Ansvaret for definisjon og oppfølging av konseptet i 
prosjektets løp ligger mest direkte hos prosjektlederen. Er prosjektet for stort 
til at du kan gjøre dette alene, må du definere et eget delprosjekt bare for 
denne oppgaven. Og vær ikke gjerrig her. For et prosjekt på noen titalls årsverk 
er 5-10% av innsatsen for oppfølging av konseptet ikke urimelig. Men slipp aldri 
dette delprosjektet av syne, for det er på konseptplanet du finner grunnlaget 
for viktige avgjørelser når overraskelser melder seg. Konseptet definerer 
systemets hovedkomponenter, og grensesnittene mellom dem. Hvis konseptet kan 
uttrykkes i en oversiktlig simuleringsmodell, vil det være til stor hjelp både 
for å tydeliggjøre konseptet for alle berørte, og for å følge det opp i 
prosjektets løp. Gjelder prosjektet utviklingen av et  operativt system, 
er en slik simuleringsmodell nesten en nødvendighet. Med operativt system 
forstås et system som skal benyttes av brukeren, dvs. at systemet er prosjektets 
resultat. Motsetninger kan være utviklingen av et simuleringssystem, hvor det er 
resultater fra simuleringene som er prosjektets resultat,  - eller et 
kartleggingsprosjekt.
        Oppgaven på konseptplanet bør du 
håndtere fullt ut innenfor prosjektet i egen organisasjon. Medvirkning fra 
eksterne parter i disse oppgavene vil lett føre til svekkelse av styringen og 
ansvarsforholdene i prosjektet. Hvis slikt samarbeid ikke kan unngås, må du 
finne arbeidsformer som sikrer at konseptarbeidet foregår i din nærhet, - innen 
daglig lunsjavstand. Selv om du etter hvert skulle få problemer med tid til 
daglig felleslunsj, må du prøve å prioritere regelmessig omgang med konsept- og 
metodefolkene. Det er de som kan holde deg oppdatert på det du fremfor alt må 
vite.
Metodegrunnlaget
Det er 
ikke uvanlig at innovative prosjekter startes fra et mangelfullt grunnlag med 
hensyn til metoder eller teknologi. Her ligger en betydelig utfordring for 
prosjektlederen. Du må trenge til bunns i karakteren av problemet, også om det 
ligger utenfor ditt eget fagfelt. Hvis funksjonen(e) det gjelder er viktig(e), 
og usikkerheten mht til å lykkes innenfor tid og ressursrammene er reell, kan 
det være aktuelt å legge opp parallelle løp. Bedømmes vanskelighetsgraden som 
meget stor, kan det være aktuelt å få startet opp grunnleggende 
forskningsaktiviteter, f.eks. dr.-gradstudier, for å skape et bredere og dypere 
faglig grunnlag. Slik virksomhet vil kanskje ikke gi anvendbare resultater 
innenfor prosjektets tidsfrister, men kan skape basis for et senere 
forbedringsprosjekt dersom resultatene fra ditt prosjekt gir grunn til  det. En 
slik grunn kan være at prosjektet har lykkes, og motiverer innsats for 
ytterligere forbedringer. Eller, i verste fall, at du ikke kom i mål, men at så 
meget ble oppnådd at oppdragsgiveren aksepterer en forsinkelse og fordyrelse for 
å nå målene.
Organisere prosjektet
Den praktiske organiseringen vil påvirkes av forhold som er spesielle for 
prosjektet. Dette skal vi la ligge, men se på et par generelle hensyn.
        To overordnede hensyn må ivaretas: 
God og åpen intern kommunikasjon, og en klar beslutningsstruktur. Pass på at 
disse hensyn ikke kommer i motsetning til hverandre, - det er ikke nødvendig. 
Straks prosjektet er større enn at den interne kommunikasjonen ivaretas i 
forlengelse av lunsjen, kan det være behov for å sikre den gjennom mer eller 
mindre formelle faggrupper og koordinatorfunksjoner på kryss i den formelle 
prosjektorganisasjonen. Men vær tydelig nå. Koordinering er et farlig ord. Det 
innebærer informasjonsdeling, - utmerket. Det kan også innebære en prosess for 
avklaring av beslutninger, - det er også greit så lenge alle blir enige og 
beslutningene tjener prosjektets mål på konseptnivå. Faren er at 
koordineringsprosessene kan få karakter av fremforhandling av kompromisser for 
faginteresser, uten at noen sjekker resultatet mot de overordnede 
prosjektmålene. Eller at de koordinerende rett og slett ikke blir enige, - en 
sikker kilde til rot og forsinkelser. I verste fall også til undergraving av 
prosjektets mål.
       
Altså: Informasjonsutveksling og koordinering understøtter, men erstatter aldri 
klare linjer for beslutninger. Linjer med definerte ansvar og tilsvarende myndighet. 
Vær også oppmerksom på at dette gjelder uavhengig av medarbeidernes dyktighet og 
erfaring. På tokt med loslauget er man nøye med å avtale hvem som 
navigerer, sies det.
Eksternt samarbeid
I et 
prosjekt av noen størrelse vil vanligvis deler av prosjektet utføres i 
organisasjoner utenfor prosjektet. Dette er kurant så lenge det dreier seg om 
bidrag på det laveste nivå i systemtrekanten. Bidraget blir da en 
"underleveranse" etter en utarbeidet spesifikasjon. Hvis spesifikasjonen 
inneholder det den skal og leveransen stemmer med spesifikasjonen, er alt vel. 
Men stol ikke på noen av delene. Sørg for faglig oppfølging under veis fra 
prosjektet, ikke bare fremdrift og penger, men at leveransen faktisk vil passe i 
systemløsningen.
        Hvis "fremmedytelsen" også berører 
metodenivået i systemtrekanten, må du sørge for et faglig samarbeid, ikke 
bare en merkantil innkjøpsavtale. Du må sikre deg at nøkkelpersonene på 
metodeplanet har en skikkelig, felles forståelse av prosjektet. Særlig i starten 
kan møter være en god investering, e-post alene er ikke nok i denne fasen.
        Det er også grenser for hvor mange 
eksterne samarbeidsparter du kan ha. Spesielt i små prosjekter kan det være fare 
for at så meget av tiden går med til å drive samarbeid at det ikke blir tid til 
eget arbeid. En tommelfingerregel kan være å holde antallet eksterne 
samarbeidsparter lavere enn antallet medarbeidere på konsept- og metodenivå i 
eget prosjekt. Tenk på prosjektet som et fysisk legeme: uten et visst volum i 
forhold til overflaten kan evnen til å absorbere og omsette energi bli mindre 
enn utstrålingen.
Risikostyring
Risikostyring er et fett ord som gjerne brukes for å gi inntrykk 
av at risikoen kan bringes "under kontroll", og derfor egentlig ikke behøver å 
eksistere. Du vil oppleve virkeligheten annerledes, men meget kan gjøres for 
unngå unødig risiko. Som prosjektleder må du ha en klar forståelse av 
prosjektets risikoprofil, dvs. de forskjellige usikkerhetenes mulige 
konsekvenser for prosjektets overordnede mål, ressurs- og tidsrammer. Ressursene 
må disponeres ut fra denne risikoforståelsen. Ettersom du aldri vil ha budsjett 
stort nok til å dekke opp for alle tenkelige usikkerheter, er sinnbildet at du 
skal tilstrebe den jevnt fordelte utilstrekkelighet, sett i forhold til 
konsekvensene på konseptplanet. Deretter får det stå til, 
inntil risikobildet eventuelt endrer seg.
Den vanskelige 
samtalen
Selv med 
stor fleksibilitet i tilpassing av oppgavene kan du oppleve at en medarbeider 
til tross for høy motivasjon ikke strekker til i de utfordringene prosjektet byr 
på. Hvis du gruer deg til å fortelle vedkommende det, skal du vite at 
vedkommende selv normalt er klar over sine begrensninger og sannsynligvis lider 
under forsøk på å bevise det motsatte. Ikke fordyp dere i alt som ikke går bra, 
men ta utgangspunkt i vedkommendes sterkeste sider, og avklar hva slags type 
jobb som kan passe. Hvis det betyr ny arbeidsgiver, kan du kanskje være til 
hjelp med råd og referanse, og glede deg ved å bidra til en ny start og en 
vellykket fortsettelse. Den vanskelige samtalen er ikke så vanskelig allikevel. 
Heller før enn senere.
Forsinkelser – som 
vanlig
Forsinkelser vil 
oppstå i innovative prosjekter. Det er nærmest naturbestemt. Så du sørger for at 
det ligger litt slakk i prosjektplanen, dvs at tidsfristene for del-aktivitetene 
er litt strammere enn nødvendig om de alle ble overholdt. Videre må du ha klart 
for deg sammenhengen mellom del-aktivitetene. Et formelt prosjektstyringsverktøy 
er meget nyttig, selv for et lite prosjekt hvis det er mange aktiviteter og 
flere aktører. Men uansett god planlegging og oversikt unngår du ikke 
forsinkelser i prosjektets løp.
        En påregnelig årsak er forsinkelser i 
bemanningen. Det er alltid kamp om flinke folk i en organisasjon, så uansett hva 
prosjektplanen sier vil bemanningen ligge etter planen i starten. Og lenger 
etter, jo større prosjektet er. Faktisk er det størrelsen av gapet mellom plan 
og virkelighet som blir ditt argument overfor høyere ledd, og som gir 
(forsinkede) resultater. Frustrerende selvfølgelig, men altså helt vanlig. 
Resultatet blir ikke nødvendigvis bedre om du står for rekrutteringen selv.
        Så kommer etter hvert alle de 
uforutsette problemene som trekker i samme retning, ting tar mer tid enn 
forutsatt. Problemstillingen er altså hvordan truende overskridelser av 
sluttdato og budsjett håndteres. Så langt som mulig vil du foreta interne 
omdisponeringer. Hvis det blir klart at dette ikke er nok, må du legge frem 
situasjonen for oppdragsgiverne. Da står du ved et meget kritisk punkt. Det 
avgjørende nå er å beholde tilliten til prosjektet. I praksis unngår du ikke at 
dette blir et spørsmål om tillit til deg selv som leder. En regel kan være at du 
må legge frem saken minst dobbelt så langt tid før forsinkelsen inntrer, som 
forsinkelsens lengde. Hvis eksempelvis sluttdatoen må forskyves tre måneder, må 
du si fra senest seks måneder før den opprinnelige sluttdatoen. Hvis 
konsekvensene for oppdragsgiveren av forsinkelsen er store må du komme 
tidligere. Og så legge frem et realistisk opplegg for å levere mot den nye tids- 
og kostnadsplanen. Sjansene er da erfaringsmessig gode for å bevare 
tillitsforholdet og oppdragsgiverens støtte.
        Det du absolutt må unngå er glidende 
estimater, i ekstreme fall å kunngjøre en ny måneds forsinkelse hver måned, 
eller å avlyse en prosjektoverlevering dagen før. Slikt undergraver tillit 
raskere og mer ødeleggende enn tilbakeslag i faglige utfordringer.
Lederansvaret
Nå tenker vi 
kanskje det samme: Har du myndighet nok til å følge opp alt dette?  Hva med 
styringsgruppen? Prosjektrådet? Brukergruppen? Sjefen? Organisasjonens forskjellige 
fagansvarlige? Dette kommer vi tilbake til i Lede organisasjon. Her nøyer vi 
oss med å slå fast at slik myndighet må du ha, dersom du skal lede prosjektet.
          Og lede må du, ikke bare administrere, hvis prosjektet skal gå bra. 
Som sagt ovenfor starter innovative utviklingsprosjekter alltid med betydelig 
usikkerhet. Det setter vilkårene for gjennomføringen, og ikke minst for 
medarbeidernes arbeidssituasjon. Vellykket gjennomføring stiller alle de krav 
man vanligvis legger i en lederfunksjon, og her med særlige utfordringer knyttet 
til de mange faglig forankrede valgene. Så fullmakter må du ha. Men la ikke 
formalitetene bli en fiksering. Under høyt stress kan det være bekvemt å ha noe 
å skylde på. Vær sikker på at det ikke er ditt eget mot til å utnytte 
fullmaktene som er din egentlige begrensning.
          Du kommer ikke unna at det er meget krevende å lede et innovativt 
utviklingsprosjekt. Og mer så, jo større prosjektet og risikoen er. Underveis vil du kanskje 
spørre deg selv om det er innsatsen verd. Svaret, når prosjektet er fullført, må 
naturligvis være ditt eget. Men bli ikke forbauset om du opplever det mange har 
opplevd før deg, at utfordringen etterlater varige spor: En skjerpet evne til å 
skille vesentlig fra uvesentlig, ettergivenhet i smått og fasthet i stort, 
uavhengighet i forhold til omverdenens tause avstand når du har motbør, og 
ukvalifiserte bifall og synlige nærhet når det går godt. Du har gjennomgått et langvarig intensivkurs i håndtering av mange 
av livets utfordringer.
        Så er det kan hende nok med ett kurs? Kanskje 
det. Men 
kanskje blir risikosportens fristelser uimotståelige.  
       
[Forord]  
[Innledning]   
[Lede eget arbeid]   
Utskriftversjon pdf   
Til hovedsiden