Back

Prosjektstyring av IT-prosjekter

av Espen Joranger

Den følgende beskrivelsen av utfordringer i prosjektarbeids, er erfaring gjennom 9 års prosjektarbeid og igjennom disse årene har jeg ofte erfart at klassisk prosjektstyrings teori ikke alltid er bruklig i et reellt prosjekt. De største utfordringene materialiserer seg når prosjektet gjennomgår forandringer. Prosjektene som her beskrives er IT prosjekter. IT-prosjekter er den prosjekttypen som er utsatt for størst usikkerhet, og det er derfor her viktig å ha en formening om de problemer et prosjekt kan gjennomgå som følge av endringer.

Et hvert prosjekt gjennomgår en rekke faser fra start til slutt. Svært få prosjekter er så heldig å ikke utsettes for forandringer i løpen av prosjekttiden. Dette innebærer at både omfanget og endelig prosjektmål vil endre seg. Dette er en både tidkrevende og kostbar del av prosjektet, og jo bedre forståelse man har av denne siden av prosjektet, jo mer kan man fokusere på prosjektets opprinnelige mål. Stort sett tar prosjektet de kostnader som slike endringer representerer uten å spørre om de de er drevet frem av kunden eller prosjektet. Alle prosjekter er forskjellig, og alle prosjekter krever sin egen innfallsvinkel, men det ville være farlig å avskrive de grunnleggende regler for prosjektigjennomføring, da man fort vil finnes seg selv vandrende i en tåkete hverdag av ansvarsfraskrivelse fra alle parter om ikke grunnleggende regler etableres fra førsten av. Om man på den andre siden overdriver prosjektstyringen, blir dette en støyfaktor i prosjektet som vil kreve uforholdsmessige store ressurser uten en målbar nytte.

Om prosjektet blir pålagt en form for rentabilitet, husk da på at prosjektets virkelige gevinster antagelig vil materialisere seg ikke-operasjonaliserbare inntekter, og kan derfor ikke føres på prosjektet, men som en gevinst for 'miljøet' på lang sikt.

Roller

I et prosjekt har man prosjekt-leder og prosjekt-medarbeidere på den ene siden og prosjekt manger på den andre siden som utgjør det formelle kontaktpunktet til den permanente organisasjonen. Ofte er prosjekt manager det samme som linjelder i den permanente ogansisjonen. Prosjekt manger trenger ikke nødvendig vis å ha konkrete kunnskaper om IT, men han må være istand til å forholde seg til problemstillingene prosjektet står ovenfor. Hvis så ikke er tilfelle, er det fare for at grensesnittet mellom prosjekt og permanet oganisasjon ikke fungerer. Prosjektet frikobler seg selv fra den parmanente organsisasjonen og prosjekt leder fungerer som et 'tolkningsleddd' mellom prosjekt og ikke-operasjonaliserbare målsetninger fra prosjekte manager. I dette tilfelle kan det være fornuftig å innføre et element fra ISO-9002, der alle avgjørelser (og ikke-avgjørelser) i prosjektet dokumenteres for å kunne begrunne eventuelle feilskjær i prosjektet når status gjøres opp (og en evntuelle kostnadsoverskridelser kan dokumenteres og begrunnes ovenfor kunden).

Planer

Det er selvsagt nødvendig å ha etablert en plan før man går igang, men jo mer detaljert denne er, jo mer ubrukelig blir den når prosjektet gjennomgår forandringer. Til slutt sitter man igjen med en opprinnelig plan som ikke kan benyttes til noe annet enn til et historisk dokument. Om prosjektet er av en visst omfang vil prosjekt leder måtte rapportere fremdrift til prosjekt manager, og det vil derfor være nødvendig med planer som sier noe om nåværende situasjon i prosjektet (current plan) og hvordan man forventer situasjonen vil være når prosjektet avsluttes (forecast plan). I IT prosjekter har det skjelden noen hensikt å måle fremdriften med prosentvis ferdigstillelse av hver aktivitet. Det vil gi et bedre bilde av den reelle situasjon å etablere felles milepæler for prosjektet og måle etter disse. Jo ferre milepæler, jo 'grovere' blir fremdriftsresultatene, men det kan være en et bedre styringsdokument i den daglige driften av prosjektet (ved at man unngår støy der man fokuserer på mål istedenfor milepæler). Man ser gjerne disse fremdriftsplanene i henhold til hverandre med S-kurver.

Endringer

Enkelte ganger er man så heldig at prosjektet tas med på råd i endrings prosessen. Om så er tilfelle har prosjektet en unik mulighet til å presentere både tid- og kostnads-konsekvenser før disse endringene gjøres gjeldene som prosjektmål, og ansvar for resultatet blir enkelere fordelt mellom Prosjekt manager og Prosjekt leder. For at dette skal bli så enkelt som mulig for begge parter, kan det være lurt å ha etablert;

  • Et variasjonsordre system, der prosjektet identifiserer endringen og får prosjekt manager til å signere denne og eventuellt stadfeste at endringen er et resultat av ønsker fra den permanente organisasjonen.
  • Etabelerer grafiske endringsmodeller som et diskusjonsgrunnlag.
  • Enkelt personer i den permanente organisasjonen må gjøres ansvarlig for å gi prosjektet input.

    Ofte er IT-prosjekter en del av et større re-engineerings arbeid, og i den forbindelse opplever man gjerne at forbedringspotensiale er omvendt proposjonalt med med endringspotensiale. Om dårlige løsninger og arbeidsprosesser har fått slått rot i en organsiasjon skal det mer til enn IT-arbeid for å løse opp i problemet. Det beste er selvsagt at arbeidet med arbeidsprosessene er fullført før IT-prosjektet startes, men om det motsatt er tilfelle vil prosjektet kunne møte motstand fra den permanente organsisasjonen.

    Kvalitet

    Kvalitet er et av de mest misbrukte ord i prosjektsammeheng, og svært mange bruker ordet galt. Kort fortalt går kvalitets begrepet ut på forutsigbarhet (riktig kvalitet) i henhold til kundens spesifikasjoner, som alltid er en kompromiss mellom;
  • fysisk kvalitet,
  • tidsforbruk og
  • kostnader
    En optimal kombinasjon av disse faktorene er den maksimale kavalitet. Om man i utgangspunktet har igjennomdiskutert hva som er god kvalitet, har prosjektet en god norm å holde seg etter, og kan brukes flittig i diskusjon med oppdragsgiver ved senere anledninger.

    Prosjekttyper

    I de fleste tilfeller er prosjektets kostander timebasert og ikke fastpris. Omfanget av prosjektet (scoop) eller prosjekt-spesifikasjon, bør være drevet frem av oppdragsgiver i timebaserte prosejekter, men med støtte av prosjektet. Det er alltid den permanente organsisasjonen som har alle spørsmålene, og prosjektleder som har alle svarene. Et kost-effektivt forhold mellom spørsmål og svar finner man først når samarbeid oppnås. En fastpris modell kan bli svært dyr for oppdragsgiver om ikke prosjekt-spesifikasjonen ikke er tilstrekklig gjennomført og en rekke endringer må igjennomføres. På den andre siden må prosjektet selv dekke kostnader for overskridelser innenfor den avtalte prosjek-spesifikasjonen. Denne modellen bør kun bruker når oppdragsgiver er istand til å spesifisere i deltalj hva som skal gjøres, og prosjektet bør kun akseptere en fastpris-modell om produktet som skal produseres bygges opp fra bunnen av (dvs. ikke re-engineering).

    Oppfølging

    Et prosjekts fremdrift og ressursforbruk bør alltid følges opp med utgangspunkt i den masterplanen,
  • for å kunne rapportere status til prosjekt manager, og gi vedkommende mulighet til foreta kursendringer, og
  • for å bevisstgjøre alle prosjektmedarbeiderene, og sørge for at alle jobber med de riktige aktivitetene. Fremdriftsoppfølgningen kan gjøres ved hjelp av å sjekke mot oppnådde milepæler, eller å sjekke den prosentvise fremdriften for hver enkelt definert aktivitet. Iogmed at IT-prosjekter ofte utsettes for uforutsette interne og ekstrne faktorer, er milepælsfremdrift å foretrekke. Ved å kombinere fremdrift og kostnadsoppfølgingen (fremdrift i % delt på brukte timer), får man et produktiviteten i et prosjekt, som sier noe om helsetilstanden i prosjektet. Om man kun foretar oppfølging av prosjektet for å rapportere oppover, går man glipp av gevisten ved å bevisstgjøre prosjektmedarbeidere, og som gir dem et innblikk i prosjektets genrelle status.

    Optimaliseringspunkt

    Alle som har jobbet med et eller annet form for prosjekt har erfart at det er en sammenheng mellom innstasfaktorer og nytte, og disse ikke alltid er 1:1. Som et eksempel, tenk kan man forestille seg en varm sommerdag, og x antall pils der man skal måle nytten av hver enkelt pils. Jo høyere nytte man føler av hver enkelt pils, jo mer er man villig til å betale for den. Det jeg her ønsker å vise, er at i en del av prosjektforløpet vil forholde mellom nytte og innsatsfaktorer være gustigst (mest nytte for færrest innsatsfaktorer) Det vil benyttes en modell fra klassisk soialøkonomi for å illustrere poenget;


    Den marginale grensenytte
    Legg spesiellt merke til de to firkantene (grønn og rød). Den grønne firkanten representerer den del av forløpet der forholdet (delta) mellom nytte og ressursforbruk er høyest, eller med andre ord der man får igjen mest (i nytte) for hver innsatsfaktor (timer eller kroner). Ifølge teorien har man her nådd et optimum. Om man invistrerer mer i prosjektet vil man fortsatt ha en nytt økning men den relative nytten vil avta helt til man kommer til toppen (den røde firkanten). Her vil man oppleve en negativ nytte av hver investert innsatsfaktor (produktet som skal produseres er blitt så kompleks at prosjektet har mistet oversikten og uhånterbare feil begyner å melde seg på grunn av kompleksiteten).

    Dette er en svært enkel måte å beskrive prosjektforløpet på. Det som er vikrleig interessant er når man oversetter endringer i prosjektet til endringer i kurven. Man kan f.eks tenke seg at;

  • Ny teknologi gjør det raskere å realisere komplekse løsninger, og kurven strekkes oppover, dvs. færre innsatsfaktorer gir høyere nytte.
  • Om det velges en enklere teknologi (f.eks regneark vs. database), vil kurven flate seg ut, og de marginale nyttegevister pr. innsatsfaktor vil bli mindre. Man bør derfor hele tiden har denne kurven i minne, når prosjektet går inn i endringerfasen, og gjøre seg opp en ide om hvor på kurven en befinner seg. For å gjøre det hele enklere, kan man dele opp prosjektet i delmoduler, og operere med en kurve for hver modul.

    Konklusjon

    Etter å ha jobbet med prosjekter i 9 år, vil jeg konkludere med følgende;
  • Oppdragsgiver må ta ansvar for prosjekt spesifikasjonen (scoop), evnt. ved hjelp av prosjektleder, før prosjektet etableres. Med andre ord må oppdragsgiver/den permanente organsisasjonen inkluderes i prosjektets løpende virksomhet.
  • Den person som skal ta over det faglige ansvaret for produktet, nor prosjektet er oppløst, bør utpekes samtidig som prosjektet startes opp.
  • Brukerdokumentasjon til systemet (IT prosjekt), bør utvikles av den permanente organisasjonen (ikke prosjektet). Dette vil forenkle lærefasen iforhold til den eller de som overtar systemet, samtidig som at det i dokumentasjonen blir lagt vekt på det som er viktig for kunden, og ikke for prosjektet.
  • Ved stor usikkerhet (som er tilfelle ved IT prosjekter), bør master planen lages som en aktivitetsliste. Noe annet vil kun skape støy i organisasjonen.
  • Ethvert prosjekt har et spesifikt omfang. Jo større usikkerhet det er knyttet til prosjektet, jo større margin må det legges inn i prosjektet, slik at den endelige løsningen kan tilpasses de optimale løsninger.
  • Oppfølgingen av prosjektet bør gjøres ved hjelp av milepæler.
  • Prosjektet må kunne forvente forpliktenede forhold mellom oppdragsgiver. Å fungere som en Project manager krever at man har kjennskap til prosjektledelse. Det er svært uheldig for et prosjekt å benfinne seg selv i et tolkningsrolle mot ikke-operasjonaliserbare innspill fra oppdragsgiver. Prosjektet må kunne aktivisere og sette krav til oppdragsgiver.
  • I prosjektfasen der endringer diskuteres, bør man visualisere endringene i form av klassiske sosialøkomiske modeller (slik de her er beskrevet). Konfronter oppdragsgiver med kurvene, og forklar den akutelle plasseringen av prpsjektet langs kurven.
  • En klassisk feil er å akseptere oppdragsgivers visjoner, før prosjektet igangsettes, for så å realisere visjonene slik man tror oppdragsgiver har utrykket dem. Gjennomdiskuter visjonene, og konfronter oppdragsgiver med problemer som kan oppstå i arbeidet med å gjøre visjonene til virkelighet.
  • Om prosjektet er en del av et større re-engineeringsprosjekt og ikke arbeidsprosessene er gjenneomgått før prosjektet starter kan resultatet bli at prosjektet blir utsatt for belastninge.
  • Prosjektet's scope bør legger opp ihenhold til endringspotensiale i organsiasjonen. Er denne lav, bør prosjektets omfang være tilsvarende beskjedent. Det er opp til den permanete organisasjonen og evnt. øke endringerpotensiale ved hjelp av å arbeide på arbeidsprosessene i forkant av IT-prosjektet

    Begreper

  • Prosjekt manager - ansvarlig for oppfølgning fra oppdragsgiver eller den permanente organsisasjonenen. Kontaktpunkt mot prosjekt.
  • Prosjekt leder - ansvarlig for oppfølgning fra oppdragsgiver eller den permanente organsisasjonenen. Kontaktpunkt mot oppdragsgiver.
  • Prosjekt medarbeider - ufører de konkrete oppgaver i prosjektet.
  • Timebasert modell - Prosjektet får betalt av oppdragsgiver ihenhold til hvor mange timer som er benyttet.
  • Fastpris modell - Oppdragsgiver og prosjekt avtaler en fast pris i henhold til et detaljert prosjektomfang, samt timerate (som vanligvis er relativt høy) for alt arbeid utover det avtalte prosjekt omfanget.
  • Master plan - Den fremdriftsplan som er grunnlaget for beslutningen om at prosjektet igangsettes
  • Current progress - Det som reellt sett er gjort enten med utgangspunkt i oppnådde mileåæler eller antatt prosentvis gjennomførte akviteter.
  • Current plan - Den fremdriftsplan som igjenspeiler alle endringer i prosjektet med utgangpunkt i Master plan
  • Forecast plan - Den fremdriftsplan som man kan ved hjelp av
  • S-Kurver - En form for grafisk presentasjon, der fremdrift utgjør Y-aksen (fra 0% til 100%), og tid langs X-aksen.


    Everything changes, nothing remains without changes.--Buddha


    From the homepage of Espen Joranger