1. Forstudiefasen Oversikt over forstudiefasen

Transkript

1 Greta Hjertø Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D 1. Resymé: I denne leksjonen skal vi ta for oss den første fasen i systemutviklingsprosjektet - forstudiefasen. Det er i denne fasen vi legger grunnlaget for prosjektet. Det gjør vi gjennom å bestemme mål og rammebetingelser, og ved å gjøre en vurdering av om prosjektet er lønnsomt og om det finnes trusler som kan hindre oss i å gjennomføre prosjektet på en god måte Oversikt over forstudiefasen Hensikten med et forstudium er kort fortalt å finne ut om det skal gjennomføres et prosjekt og i så fall, i grove trekk hva slags prosjekt. Forstudiet er en innlednings- og orienteringsfase før det egentlige prosjektarbeidet. I forstudiet skal vi skaffe oss oversikt over hva prosjektet skal dreie seg om, vi skal avgrense prosjekt, og vi skal finne fram til en fornuftig angrepsmåte for arbeidet. Forstudiet skal gi oss tilstrekkelig informasjon til at vi kan vurdere om dette prosjektet er lønnsomt å gjennomføre. Vi forutsetter her at forstudiet og resten av prosjektet gjennomføres som et samarbeid mellom to parter: Oppdragsgiveren: - som har et problem og er villig til å betale for å få løst problemet Oppdragstakeren: - som påtar seg et oppdrag og skal komme fram til en løsning på oppdragsgiverens problem. Senere vil vi bruke systemutvikler som begrep for oppdragstakeren, både fordi det da er lettere å skille mellom de to partene, og fordi dette handler om systemutvikling. Oppsummert er hensikten med forstudiet å komme fram til: - Prosjektets mål basert på en vurdering av brukerens behov og problemer med dagens situasjon - Lønnsomheten av prosjektet gjennom en sammenstilling av forventet nytteverdi mot forventede kostnader - Strategi og overordnede planer for gjennomføringen - Tids og ressursbehov for gjennomføringen

2 Dette er grunnlag for å beslutte om det skal gjennomføres et prosjekt, og på overordnet nivå, hva slags prosjekt som skal gjennomføres. Forstudiet er videre grunnlag for en formell avtale mellom oppdragsgiveren og systemutvikleren om å gjennomføre prosjektet i henhold til mål og rammer i forstudiet. Hvis oppdragsgiveren sier ja, forplikter han seg samtidig til å finansiere neste fase i prosjektet. Problem, ide, prosjektforslag Forstudium Mål Tid og kostnader Lønnsomhetsvurdering Strategi og planer Ja Analyse Nei, stopp! Når vi har bestemt at det skal gjennomføres et prosjekt må det inngås en avtale mellom oppdragsgiveren og systemutvikleren hvor begge parter forplikter seg til å gjennomføre arbeidet innenfor de rammene som er gitt, og til å skaffe nødvendige ressurser. Oppdragsgiveren styrer prosjektet videre gjennom prosjektets styringskomite Hva er grunnlaget for å starte et forstudium? Før vi kan starte et forstudium må vi ha: - En oppgavebeskrivelse - En avtale om gjennomføring Oppgavebeskrivelsen kan være mer eller mindre klart formulert. I Leksjon: Introduksjon til systemutvikling har vi beskrevet en del typiske utgangspunkt for å starte et systemutviklingsprosjekt. Felles for dem alle er at noen i oppdragsgiverens organisasjon har identifisert et problem, et behov for endring eller en mulighet som bør utnyttes. Utgangspunktet kan være dokumentert som et prosjektforslag, det kan være prioritert i en ITstrategi, eller det kan finnes som tanker og ideer i hodet til folk. Uansett form og innhold av oppgavebeskrivelsen, vil mye av arbeidet i forstudiet gå ut på å utdype problemstillingen gjennom intervjuer, dokumentlesing, idedugnader, etc. for så i forstudierapporten å beskrive temmelig detaljert det prosjektet som (eventuelt) skal gjennomføres. I tillegg til oppgavebeskrivelsen må det før starten av et forstudium finnes en (presis) avtale mellom oppdragsgiveren og systemutvikleren om arbeidet i forstudiet: - Hva som skal gjøres i forstudiet - Hva det skal koste - Hvor lang tid det skal ta - Hvem som skal delta. side 2 av 17

3 Hva som skal gjøres i et forstudium er gjerne beskrevet i en prosjektmodell eller i en standard som bedriften har. I avtalen sørger vi for at standarden tilpasses vårt prosjekt med den problemstillingen som skal behandles De viktigste oppgavene i forstudiet Arbeidet i forstudiet blir et tett samarbeid mellom oppdragsgiveren og systemutvikleren. Oppdragsgiveren skal: - Gi rammer for forstudiet - Fremskaffe nødvendig informasjon om egen virksomhet og problem og bakgrunn forprosjektet - Stille eget personell til disposisjon som avtalt - Formulere forventet nytte av prosjektet - Sørge for at resultatet av forstudiet blir verifisert av personell med riktig kompetanse. Systemutvikleren skal: - Sørge for at mål og rammer og forventet nytteverdi for prosjektet blir kartlagt og dokumentert basert på informasjon fra oppdragsgiverens organisasjon - Foreslå en overordnet strategi for prosjektgjennomføring basert på prosjektets karakteristika, dette kan for eksempel være overordnet valg av teknologi, det kan være omfang, det kan være kjøp kontra utvikling og så videre. - Fremskaffe og dokumentere estimater for kostnader, tid og ressursbehov for gjennomføring av prosjektet - Foreslå en prosjektorganisasjon. Sammen skal systemutvikleren og oppdragsgiveren sikre at prosjektet forankres på riktig måte i organisasjonen, se leksjon: Introduksjon til systemutvikling Viktige for å lykkes med et forstudium Forstudiet er en viktig fase i prosjektets liv, det er her vi bestemmer hva slags prosjekt dette blir. Vi må derfor være ekstra omhyggelige i starten slik at vi velger riktig. Vi har i leksjon Introduksjon til systemutvikling brukt som eksempel et IT-system for reiseregnskap i en bedrift. Vi har sett at det med utgangspunkt i samme problemstilling kan besluttes å gjennomføre vidt forskjellige prosjekter: - Et prosjekt som satser på å gi de som jobber i reiseregnskap et bedre system slik at de kan jobbe omtrent som før, men får bedre støtte til jobben. - Et system som gjør mange i reiseregnskap overflødige, slik at de mister jobben sin. Det er lett å se at dette betyr forskjellige kostnader, forskjellig tidsperspektiv, forskjellig ressursbruk og veldig forskjellig resultat for bedriften. Hva er riktig angrepsmåte? Svaret kommer som et resultat av forstudiet. Det må derfor legges stor vekt på gjennomføring av forstudiet. Spesielt bør vi være oppmerksomme på: - Forankring av forstudiet hos oppdragsgiveren. Det må opprettes kontakt med de virkelige problemeierne (brukerne) og det må eies av en beslutningstaker tilstrekkelig høyt oppe i organisasjonen. side 3 av 17

4 - Valg av prosjektleder. Den som skal lede et forstudium bør ha erfaring og oversikt. Når prosjektet er styrt inn på rett vei kan det eventuelt overlates til en mindre erfaren prosjektleder hvis det viser seg at dette er et enkelt, rett frem prosjekt. - Tilgang til informasjon hos oppdragsgiveren og verifisering av forståelse av informasjon - Prosjektgruppens evne til å kommunisere med brukerne - Måten resultatet dokumenteres og presenteres på (det må være forståelig for målgruppen). - Prosjektgruppens evne til å tenke utradisjonelt. (Det sies at hvis man har en hammer blir alle problemer spiker. Det sies også at systemutviklerene mangler evnen til å se for seg andre løsninger enn store, tunge flerbrukersystemer utviklet i årelange prosjekter som følger fossefallsmodellen) Oversikt over resultatene av forstudiet Dette er de viktigste resultatene fra forstudiet, og vil bli beskrevet nærmere i neste kapittel: 1. Dagens situasjon bakgrunn for prosjektet 2. Prosjektmål 3. Prosjektets omfang 4. Konsekvenser for organisasjonen 5. Rammebetingelser 6. Kritiske suksessfaktorer 7. Risikoanalyse 8. Kost/nytte analyse 9. Forslag til prosjektorganisasjon 10. Retningslinjer og standarder 11. Aktivitets- og ressursplan 12. Anbefaling om videre arbeid 1.2. Nærmere om de viktigste resultatene av forstudiet I dette kapitlet beskriver vi kort de viktigste prosjektresultatene som skal produseres i forstudiet. Vi sier lite om hvordan prosjektgruppen skal komme frem til resultatene og hvilken form dokumentasjonen av dem skal ha. Grunnen er at de prosjektresultatene vi skriver om er allmenngyldige for de fleste prosjektene de skal produseres. Hvordan vi produserer dem derimot, vil variere. Prosjektet stiller mye friere når det gjelder både å velge metoder og teknikker for arbeidet og hvordan resultatet skal dokumenteres. Det finnes mange måter å gjøre det på som kan gi gode resultater. Vi har til slutt i denne leksjonen tatt med en liste over metoder og teknikker som kan være aktuelle i forstudiet. Denne lista er på ingen måte utfyllende. Husk at dokumentasjon i denne fasen i stor grad produseres for å: - få frem informasjon - verifisere at vi forstår informasjonen side 4 av 17

5 Vi sier dette, fordi vi har erfaring med at systemutviklere ofte kvier seg for å dokumentere fakta om brukerorganisasjonen brukerne vet jo dette allerede og mye bedre enn oss, hvorfor skal vi dokumentere det? Som sagt, mye dokumenteres i denne fasen for å oppnå felles forståelse hos brukerne og systemutviklerne Dagens situasjon - bakgrunn for prosjektet Beskrivelse av problemer og behov Begrunnelsen for å starte et prosjekt, er gjerne at noen har problemer med å utføre arbeidsoppgavene. I forstudiet kartlegges og dokumenteres problemene som bakgrunn for prosjektet og for å forstå hva oppdragsgiveren ønsker å oppnå. Problembeskrivelsen kan senere brukes i forbindelse med salg/markedsføring av prosjektet, og for å skape aksept i organisasjonen for å innføre og ta i bruk et nytt system. Alt som oppleves av brukeren som noe som hindrer utførelsen av arbeidsoppgavene på en effektiv måte er verdt å ta med. Det kan være problemer som oppleves daglig eller som brukerne forutsetter vil komme dersom det ikke gjøres noe. Problemene kan skyldes: - Dårlige arbeidsrutiner - Mangler i dagens system - Dårlig kvalitet på informasjonen, mangel på tilgang til informasjon - Dårlig utnyttelse av teknologien eller systemene Kort om dagens systemer og rutiner Hensikten er å gi de opplysningene som er nødvendige for å få et mest mulig komplett bilde av hva prosjektet dreier seg om, for eksempel: - Skisse av dagens systemer og arbeidsrutiner - Hvem er brukere, - Hvem eier dagens systemer og finansierer videreutvikling og forvaltning - Evt. igangsatt eller planlagt arbeid med oppgradering Prosjektmål Prosjektmålene formulerer vi som oftest med utgangspunkt i de problemene vi har kartlagt og beskrevet. Det kan imidlertid være tilfeller hvor prosjektet er startet i forbindelse med etablering av nye arbeidsområder innen virksomheten. Da vil utgangspunktet for prosjektmålene være målene for den nye virksomheten. Formulering av prosjektmål er grundig behandlet i Leksjon Prinsipper for prosjektarbeid. Prosjektmål deles hensiktsmessig inn i: Effektmål Hvilken effekt ønskes oppnådd i organisasjonen ved å gjennomføre prosjektet (for eksempel økt lønnsomhet, bedre arbeidsmiljø) side 5 av 17

6 Resultatmål Hva skal gjøres i prosjektet for å oppnå den ønskede effekten (for eksempel å utvikle et system). Prosessmål (eventuelt) Hvilken effekt vil det å arbeide i prosjektet ha på prosjektdeltagerne (for eksempel å gi økt kompetanse i et spesielt utviklingsverktøy). Prosjektets omfang Dette er et supplement til prosjektmålene og utdyper og presiserer hva prosjektet skal gjøre og hva det ikke skal gjøre slik at det ikke skal oppstå misforståelser. Beskrivelsen kan være i form av enkle modeller av funksjoner og data, i kombinasjon med, eller som tekst. Det er en god investering å presisere hva prosjektet IKKE skal gjør. Spesielt hvis vi har mistanke om at oppfatningene er forskjellige. Eksempel: - Prosjektet skal ikke erstatte system NN - Prosjektet skal ikke drive brukeropplæring Konsekvenser for organisasjonen Vi beskriver her hvordan prosjektets arbeid vil påvirke organisasjonen. Det er her viktig å presisere hvilke deler av organisasjonen som vil bli berørt. Konsekvenser av innføring av ny løsning beskrives i den grad vi har oversikt over det. Det legges vekt på å få frem det som har betydning for strategier, rutiner, tilgang til informasjon, endret samhandling med andre enheter, roller og ansvar, personalbehov etc Rammebetingelser Dette er absolutte krav som stilles til prosjektets gjennomføring og til resultatet og som vil ha avgjørende innflytelse på planer og valg i prosjektet. Det kan for eksempel gjelde: - Absolutte krav til ferdigdato - Absolutte krav til kostnadsramme - Myndighetskrav - Drifts- og utviklingsmiljø Etc. Hensikten er å sikre at prosjektplanene tar nødvendige hensyn til slike faktorer. Om rammebetingelser er videre å si at de skal være rammebetingelser. Med det mener vi at vi ikke skal dokumentere rammebetingelser av type: Det hadde vært fint om (prosjektet ikke ble dyrere enn, ble ferdig til, osv). Husk at det vi beskriver her begrenser prosjektets handlefrihet. En absolutt ferdigdato vil i høyeste grad kunne påvirke både kostnad og omfang og kvalitet. En ønskelig ferdigdato er ikke det samme som en absolutt ferdigdato Kritiske suksessfaktorer Dette er faktorer som vil være kritisk avgjørende for om prosjektets resultat vil bli vellykket eller ikke. Eksempler på slike faktorer: - Det må velges løsninger som gjør det mulig å opprettholde dagens fleksibilitet for brukerne (hva vi mener med fleksibilitet må presiseres) side 6 av 17

7 - Brukerorganisasjonen må avsette tilstrekkelig ressurser og tid til innføring og opplæring i det nye systemet og de nye arbeidsrutinene - Det må utpekes personer med tilstrekkelig kompetanse til å ivareta forvaltning og drift. Hensikten med å få frem slike faktorer er å sikre tilstrekkelig fokus på kritisk viktige forhold hos både oppdragsgiveren og systemutvikleren. Ikke finn på kritiske suksessfaktorer, men bruk tid sammen med oppdragsgiveren og prosjektgruppen til å finne frem til de som virkelig gjelder Risikoanalyse Risiko kan vi definere som sannsynligheten for at en uønsket hendelse inntreffer - og konsekvensene dersom det skjer. Med risikoanalyse menes en systematisk analyse av forskjellige forhold knyttet til dette. Analysen skal hjelpe oss til å: - finne frem til uønskede hendelser (risikofaktorer) som prosjektet må beskytte seg mot - bedømme sannsynligheten for at de skal inntreffe - analysere hvilke konsekvenser det vil få hvis de inntreffer - vurdere virkemidler som kan hindre at risikofaktoren oppstår eller som kan minske konsekvensene hvis det skjer Hva er prosjektets risikofaktorer? En risikofaktor er en hendelse som skaper en uønsket situasjon i prosjektet hvis den oppstår. Vi vil ha et tap forbundet med hendelsen: tap av tid, penger, kvalitet, kontroll, forståelse osv. Som eksempel kan vi se på hendelsen: Vår Java-ekspert slutter i firmaet. Vi vil da åpenbart få tap av kompetanse, men i tillegg vil vi sannsynligvis få tap av tid (for å finne en ny programmerer), av penger (kostnader ved å lære opp en ny), kanskje av kvalitet (vi finner ingen ny og må programmere selv) osv. Vi skiller gjerne mellom ulike typer risikofaktorer: - de generelle, slike som alle prosjekter har, slik som f.eks. at prosjektgruppen misforstår kravene, at vi mister nøkkelkompetanse, får for dårlig tid til å teste etc. - de prosjektspesifikke, slike som er spesielt for vårt prosjekt, f.eks. avhengighet til et annet prosjekt eller til at en leverandør leverer en viktig komponent innen en gitt dato - de ufrivillige, slike som påføres oss av omgivelsene rundt oss, f.eks. ved at en nøkkelperson blir syk eller slutter (vi kan sammenligne disse med risikoen for hudkreft ved at ozonlaget har hull det er lite vi kan gjøre) - de frivillige, slike som vi med åpne øyne velger å ta, som f.eks. at vi velger å bruke et verktøy vi aldri har brukt før (vi kan sammenligne disse med risikoen for hudkreft ved at vi soler oss for lenge uten beskyttelse dette gjør vi frivillig). I følge [Boehm1991] kan vi sette opp en liste over ti-på-topp risikofaktorer som de fleste prosjekter bør vurdere i risikoanalysen: 1. Mangel på kvalifisert personell eller andre problemer knyttet til personell, f.eks. samarbeidsproblemer. Dette gjelder personell både i prosjektgruppen og i brukerorganisasjonen. 2. Urealistisk tidsplaner eller budsjetter. side 7 av 17

8 3. Utvikling av feil system (!) (Det var ikke dette systemet brukerorganisasjonen trengte). 4. Utvikling av feil brukergrensesnitt. Det fungerer av ulike årsaker ikke for systemets fremtidige brukere. 5. Gold-plating (Forgylling - vi utvikler systemet med unødige detaljer eller funksjoner eller mer avansert enn det er behov for). 6. Hyppige endringer av kravene underveis. 7. Dårlig kvalitet eller forsinkelser - i systemkomponenter som utvikles av andre. 8. Dårlig kvalitet eller forsinkelser - i systemkomponenter som kjøpes inn. 9. Kapasitetsproblemer i det ferdige systemet. 10. Bruk av ny og uprøvd teknologi, eller bruk av teknologien på grensen av det den er beregnet til. I tillegg har vi erfaring med at følgende risikofaktorer bør vurderes: - Vi kjenner ikke datakvaliteten i eksisterende database, det kan bety problemer når vi skal laste over data - Det kan oppstå problemer i et annet prosjekt som vi er avhengig av på en eller annen måte, f.eks. gjennom felles grensesnitt I tillegg til begge disse listene kan det også være viktig å gjennomføre en idé dugnad for å avdekke ukjente risikofaktorer både for generelle, prosjektspesifikke, ufrivillige og frivillige risikofaktorer. Det finnes vel utprøvde og dokumentert metoder for dette, men vi skal ikke diskutere denne metodikken i dette kurset. Hva er sannsynligheten for at en uønsket hendelse inntreffer og hva blir konsekvensene (tapet)? Etter å ha identifisert prosjektets risikofaktorer, må vi gjøre en vurdering av sannsynligheten for at de inntreffer. Dette kan gjøres temmelig avansert ved å benytte ulike modeller for å beregne en sannsynlighet mellom 0 og 1 for hver faktor. (En risikofaktor som har sannsynlighet 1 vil komme til å inntreffe og vi slutter da å kalle det en risikofaktor og erkjenner at vi har et problem). Vi skal her nøye oss med en svært uformell metode for dette. Den går i all sin enkelhet ut på at prosjektgruppen tar fatt i hver risikofaktor og i samtale forsøker å forstå så mye som mulig om: Når, Hvorfor og evt. Hvor risikofaktoren kan slå til. Vurderingene dokumenteres. Vi kan fremdeles knytte en størrelse for sannsynligheten til hver risikofaktor: mellom 0 og 1, eller: Lav, Middels, Høy eller vi kan bruke en annen skala. Det som er viktig uansett hvilken skala en bruker, er at alle som deltar i risikoanalysen har en felles forståelse av betydningen av de ulike verdiene på skalaen. Det neste skrittet blir da å gjøre en konsekvensanalyse eller vurdere mulige tap for prosjektet hvis den uønskede hendelsen inntreffer. På samme måte som for sannsynligheten må prosjektgruppas vurderinger for hver risikofaktor dokumenteres. Konsekvensene kan kvantifiseres hvis dette er naturlig (i kroner og øre, i tid). I denne delen av analysen vil vi også se på spørsmål som: - Er dette en ufrivillig eller frivillig risikofaktor? - Er den knyttet til en spesiell type teknologi? side 8 av 17

9 - Hvem blir berørt hvis den inntreffer? - Er det katastrofalt hvis den inntreffer? Dette er alle spørsmål som kan gi oss bedre innsikt. Etter å ha vurdert disse to aspektene ved risikofaktorene er vi i stand til å gi hver risikofaktor en prioritet. Denne beregnes ut fra en kombinasjon av sannsynligheten for at den inntreffer og effekten hvis den inntreffer. Risikofaktorer som får høy prioritet er altså de som både har en høy sannsynlighet for å inntreffe og en stor effekt hvis de inntreffer. Hensikten med å gi en prioritet til hver risikofaktor er ganske enkelt at vi kan konsentrere ressursen i prosjektet om tiltak knyttet til de risikofaktorene som har høy prioritet. Som sagt, denne typen analyse kan gjøres mer eller mindre avansert og vitenskapelig. Det er imidlertid vår oppfatning av at de fleste prosjekter vil komme langt med en uformell tilnærming. - Det viser seg og at en alt for kvantitativ og vitenskapelig tilnærming kan ende opp med falsk presisjon og mer tilsløre enn å gi innsikt. Det viktigste er at vi går igjennom denne prosessen. Den innsikten vi dermed får i prosjektgruppa vil i de fleste prosjekter være like mye verdt som det risikotallet vi knytter til risikofaktoren. Tiltak for å kontrollere risiko For hver risikofaktor og spesielt de med høy prioritet må vi vurdere hva vi kan gjøre for å hindre at den inntreffer eller å minimalisere effekten hvis den inntreffer. Det er grovt sett tre strategier for å redusere risiko i prosjektet, og alle må vurderes: 1. Vi kan fjerne risikoen ved å endre rammebetingelsene. Vi kan f.eks. velge en annen teknologi hvis risikoen er knyttet til teknologien (nytt uprøvd verktøy), eller vi kan bemanne prosjektet på en annen måte hvis risikoen er knyttet til prosjektgruppen. 2. Vi kan overføre risikoen. Vi kan f.eks. ta inn i kontrakten med en leverandør at vi skal ha kompensasjon hvis leverandøren er for sen med en komponent, eller vi kan ta inn i kontrakten med oppdragsgiveren at prosjektets planer er avhengige av at brukerorganisasjonen stiller de riktige ressursene til disposisjon. (En annen sak er at slik overføring har en tendens til å bli prosjektets problem uansett, så vær forsiktig med å tro at du løser problemene på denne måten.) 3. Vi kan akseptere risikoen og iverksette tiltak i prosjektet for å kontrollere den. Hvis vi går tilbake til [Boehm1991] ti-på-topp risikoliste, så har han også foreslått mulige tiltak, her beskrevet i stikkordsform: - Personell: kun høyt kvalifiserte folk, flere med samme kompetanse, lagbygging, kontraktfeste ressurser, pre-allokere ressurser etc. - Tid og kostnad: estimater fra flere kilder, tidsboksing, faste kostnadsrammer, inkrementell utvikling, gjenbruk av kjente komponenter - Galt system : analyse av arbeidsprosessen og organisasjonen, brukerundersøkelser, prototyping - Galt brukergrensesnitt : prototyping, scenario analyse ( hva gjør du hvis ) - Gold-plating : kost-nytte analyse, prototyping, kategorisering og prioritering av brukerkrav (må-krav, anbefalt-krav, fint-å-ha -krav) side 9 av 17

10 - Hyppige endringer i brukerkrav: inkrementell utvikling, formell endringshåndtering - Mangler i eksternt utviklede komponenter: sjekk av referanser, belønnings-kontrakter (i motsetning til straffe-kontrakter, leverandørene belønnes for godt arbeid), inspeksjoner, lag-bygging, prototyping - Mangler i innkjøpte komponenter: benchmarking, inspeksjoner, sjekk av referanser, sammenlignende analyse (mot konkurrenter) - Kapasitetsproblemer: simulering, benchmarking, modellering, prototyping, tuning - Ny teknologi eller teknologi på grensen: teknisk analyse, kost-nytte, prototyping, sjekk av referanser. Det neste trinnet i analysen etter at vi har identifisert mulige tiltak for å kontrollere risikoen er å vurdere kostnadene forbundet med tiltakene. Vi har her en enkel leveregel som gjelder temmelig generelt: Kostnadene forbundet med å hindre at en uønsket hendelse inntreffer skal ikke overstige de kostnadene som påløper hvis hendelsen inntreffer. Dokumentasjon av risiko En god og enkel måte å dokumentere risikofaktorer på er vist nedenfor: Vi viser her risikofaktorene plottet inn i et koordinat med sannsynlighet for at de skal inntreffe langs den ene aksen og konsekvensene hvis de inntreffer langs den andre. De risikofaktorene vi virkelig trenger å bekymre oss om ligger da i øvre høyre hjørne: høy sannsynlighet og store konsekvenser. De vi ikke trenger å bekymre oss for ligger i nedre venstre: lav sannsynlighet, små konsekvenser. Sannsynlighet Konsekvenser Sammen med dette kartet beskriver vi kort for hver risikofaktor - utdyping av hva som ligger i risikofaktoren side 10 av 17

11 - hva som er avgjørende for om den inntreffer eller ikke - hvilke konsekvenser vi forutser - og for de som har høy prioritet: Hvilke tiltak vi har planlagt for å kontrollere risikoen. Oppsummert - risikoanalyse En risikoanalyse består altså av følgende trinn: 1. Identifiser prosjektets risikofaktorer. Her kan [Boehm1991]s liste som vi har vist over være til hjelp, men begrens for all del ikke risikovurderingen til disse faktorene 2. Identifiser sannsynligheten for at risikofaktorene inntreffer. Dette kan gjøres avansert ved bruk av ulike modeller, men det viktigste er antagelig å gjøre en systematisk gjennomgang i prosjektgruppa. Sannsynligheten for at en bestemt faktor inntreffer kan angis på en skala fra 0 til 1, som Høy, Middels eller Lav eller etter en annen skala. I tillegg bør prosjektgruppens vurderinger og begrunnelser dokumenteres. 3. Identifiser konsekvensene hvis risikofaktorene inntreffer. Dette gjøres ved en systematisk gjennomgang i prosjektgruppa. Hvis det er naturlig kan konsekvensene utrykkes kvantitativt i kroner og øre, eller i tid. Vurderinger og begrunnelser dokumenteres. 4. Gi hver risikofaktor en prioritet. Høy prioritet betyr høy sannsynlighet og store konsekvenser. 5. Identifiser mulige tiltak for å kontrollere risikoen (for de høyest prioriterte faktorene). Her har vi alltid tre overordnede strategier å eliminere risikofaktoren ved å gjøre nye valg, å overføre risikoen til andre, å iverksette tiltak i prosjektet for å kontrollere den. 6. For hvert mulig tiltak må vi vurdere kostnadene ved tiltaket. Et tiltak for å hindre en hendelse må aldri koste mer enn det koster hvis hendelsen inntreffer. 7. Dokumenter risikoanalysen på en enkel form, for eksempel som vist over og kommuniser den til prosjektets styringsorganer og til prosjektgruppen. En slik enkel risikoanalyse som vi har beskrevet over bør gjennomføres med jevne mellomrom i prosjektet. Analysene vil da vise utviklingen for de enkelte faktorene og er et glimrende utgangspunkt for å diskutere viktige forhold i prosjektet mellom prosjektleder og styringskomité. Det viser at prosjektleder har kontroll! En slik enkel risikoanalyse bør gjennomføres med jevne mellomrom i prosjektet. Analysene vil da vise utviklingen for de enkelte faktorene og er et glimrende utgangspunkt for å diskutere viktige forhold i prosjektet mellom prosjektleder og styringskomite. Kost/nytte analyse Dette er en viktig del av beslutningsgrunnlaget for om prosjektet skal gjennomføres. Hensikten er å avgjøre om nytten av prosjektet er verdt kostnadene ved å gjennomføre det. I analysen vil vi først gjøre et anslag av effekten av prosjektet forventet nytte. Deretter lager vi estimater for hva prosjektet kommer til å koste. Det høres muligens enkelt ut, men er det ikke. På dette stadiet i prosjektet vet vi nesten ingen ting. Vi har noen tanker og ønsker, vi ser for oss et prosjektløp. Nå må dette konkretiseres, helst i kroner og ører slik at ledelsen kan vurdere om investeringene kan forsvares. En kost/nytte analyse kan gjøres mer eller mindre avansert og vitenskapelig. I sin mest avanserte form er den svært arbeidskrevende og en oppgave for eksperter, dvs. økonomer. I side 11 av 17

12 mindre prosjekter kan det være tilstrekkelig med forenklede oppstillinger av forventet nytte og forventet kostnad og ikke minst selve prosessen ved å diskutere dette med oppdragsgiveren vil ha verdi selv om analysen er enkel. (Også når det gjelder kost/nytte er det lov å tenke kost/nytte). Uansett om vi går inn i en avansert eller en enkel analyse er det svært viktig at vi før vi starter gjør det klart hva det er vi sammenligner: - Vi sammenligner det å gjennomføre et prosjekt mot det såkalte 0-alternativet Å ikke gjøre noe. Hva prosjektet innebærer har vi beskrevet i prosjektdokumentasjonen, hva 0-alternativet innebærer må også kort dokumenteres slik at vi vet hva vi forventer vil påløpe av kostnader i fremtiden om vi ikke gjør noe. En enkel kost/nytte-analyse har følgende elementer: Kvantifiserbar og ikke-kvantifiserbar nytte. Med utgangspunkt i effektmålene vurderes verdien av den forventede effekten av prosjektet. Nytten kvantifiseres best mulig. Med kvantifisering mener vi at vi tallfester nytten, som oftest i kroner. Det er imidlertid svært viktig å beskrive nytte som ikke er kvantifiserbar da den kan være avgjørende for å velge å kjøre prosjektet. Eksempel: Effektmål: - Redusere bedriftens rentetap på for sen betaling av fakturaer med 50% av dagens situasjon - Behandle 30% flere fakturaer med samme bemanning Kvantifiserbar nytte: - Beregnet kroneverdi av redusert rentetap - Beregnet kroneverdi av økt produktivitet, det kan for eksempel være reduserte overtidskostnader eller sparte penger ved at en ikke trenger å ansette en ny person Ikke-kvantifiserbar nytte: - Mindre frustrasjon og stress hos de ansatte i fakturaavdelingen - Bedre omdømme hos leverandørene Når det gjelder den ikke-kvantifiserbare nytten er det fullt mulig å estimere en kroneverdi på denne også. Vi kan for eksempel anslå hva frustrasjon og stress koster i form av mindre produktivitet, eller vi kan anslå hva bedre omdømme vil gi oss for eksempel i bedre leveringsbetingelser. Hvorvidt vi ønsker å gjøre en slik øvelse eller ikke må vurderes i hver enkelt situasjon. Hvis vi har mulighet til forholdsvis enkelt å komme frem til tall som har reelle verdier bør vi gjøre det, men vi tallfester ikke uten et reelt grunnlag. Bortfall av direkte kostnader Her beregnes for eksempel drifts- og forvaltnings kostnader ved de systemene som vi forventer skal erstattes av det nye systemet. Bortfall av direkte kostnader er en form for nytte og tas med på pluss siden. side 12 av 17

13 Hvis vi ser dette i forhold til kvantifiserbar nytte som vi omtalte i forrige kapittel, så vil vi oppdage at skillet mellom det vi kaller kvantifiserbar nytte og det vi kaller bortfall av direkte kostnader ikke er så absolutt. Redusert rentetap som vi kalte kvantifiserbar nytte kunne vi for eksempel gjerne se på som bortfall av direkte kostnader. Det viktigste her er imidlertid ikke hvilke overskrifter vi gir de enkelte nyttefaktorene. Det viktigste er at vi får med alle og at vi ikke tar med noen flere ganger. (Altså ikke reduserte rentekostnader både som kvantifiserbar nytte og som bortfall av direkte kostnader). Estimerte kostnader Her beregnes utviklingskostnadene for det nye systemet, det vil si de totale prosjektkostnadene. I tillegg estimeres forventede drifts- og forvaltningskostnader for det nye systemet. Sammenstilling kost/nytte Her setter vi opp en tabell hvor vi sammenligner kostnadene med nytte i en periode på 3-5 år. Regnestykket kan for eksempel se slik ut (prosjekt i år1): År 1 År 2 År 3 År 4 År 5 Sum Kvantifiserbar nytte n1 n2 n3 n4 N Bortfall kostnader k1 k2 k3 k4 K Sum nytte n1+k1 n2+k2 n3+k3 n4+k4 n+k Utviklingskostnader Y Y Drifts- og forv. kostnader x1 x2 x3 x4 X Sum kostnader x1 x2 x3 x4 Y+X Beregnet nytte (nytte kostnader) -Y n1+k1 -x1 n2+k2 -x2 n3+k3 -x3 n4+k4 -x4 N+K-Y+X Forslag til prosjektorganisasjon Her gir vi en anbefaling om hvordan prosjektet bør bemannes. Her beskrives: - rollene i prosjektorganisasjonen - personer eller enheter som bør bekle rollene - krav til kompetanse - forventet innsats fra hver enkelt person - andre viktige forhold. Det bør legges spesiell vekt på å få frem ressursbehov og krav til kompetanse i oppdragsgiverens organisasjon da det erfaringsmessig er her det er størst problemer med å få tilgang til de riktige ressursene. Organisering av prosjekter er behandlet i følgende leksjoner: side 13 av 17

14 - Leksjon 2 Prinsipper for prosjektarbeid. Her introduseres rollene i en klassisk prosjektorganisasjon. - Leksjon 3 Introduksjon til systemutvikling Her beskrives en allment akseptert arbeidsdeling mellom systemutvikleren og oppdragsgiveren / bruker. Uansett hvordan vi velger å fordele oppgaver og roller er det et prinsipp som er overordnet alle andre og som vi må sørge for er oppfylt: - at alt ansvar, alle oppgaver og roller er definert og klart beskrevet, og at alle prosjektmedlemmer er kjent med sin rolle og hva den innebærer Retningslinjer og standarder I dette kapitlet skal vi kortfattet ta med de retningslinjene og standardene som prosjektet må forholde seg til. Det gjelder for eksempel: Krav til dokumentasjon Her beskrives kort hvilke (hoved) dokumenter som skal produseres i løpet av prosjektet, når de skal foreligge, på hvilken form de skal foreligge og evt. rutiner for godkjenning og revisjon av dokumentene. Krav til kvalitetsgjennomganger Her beskrives kort hvilke resultater som skal ha kvalitetsgjennomganger, hvem som skal være med og evt. standarder for gjennomføring og rapportering. Eksempel på slike resultater kan være: - Brukerkrav - Brukergrensesnitt - Logisk databaseutforming - Databasekonstruksjon Krav til standarder og metoder Her referer vi til de konkrete standarder, metoder, verktøy som prosjektet må benytte. Eksempel kan være: - Navnestandarder - Programmeringsstandarder - Dokumentmaler - Utviklingsverktøy - Databaseverktøy - Testopplegg Aktivitets og ressursplan Det skal utarbeides en plan for videre prosjektgjennomføring. Planen vil bestå av to deler: 1. En oversiktsplan for hele prosjektet 2. En detaljert plan for neste fase i prosjektet Planene bør ha følgende innhold: side 14 av 17

15 Plan for hele prosjektet 1. Inndeling i faser med angivelse av tid og ressursbehov for fasen og de viktigste resultatene som skal produseres. 2. Milepæler med dato og kriterier for å måle om milepælen er oppnådd. Milepæler kan være sentrale resultater, beslutningsmøter og andre viktige hendelser i prosjektforløpet. 3. Grov tidsplan som viser fasene lagt ut i tid, for eksempel i form av et enkelt Ganntdiagram som viser start og slutt på fasene, samt markerer milepælene. 4. Bemanningsplan: - Ressursbehov fordelt på kategori og fase - Angivelse av de enkelte ressursene med kompetanse og % tilgjengelig tid 5. Prosjektbudsjett som gir estimat for totalkostander i prosjektet - Kostander utviklingspersonell - Kostnader brukerpersonell - Kostander datakraft - Reisekostander - Investeringer i utstyr og programvare (som kjøpes inn) - Opplæringskostander - Evt. andre kostander. Plan for neste fase 1. Planlagte resultater 2. Planlagte aktiviteter med ansvarlig, ressurser, resultater, start og stopp 3. Milepæler 4. Tidsplaner i form av et Gannt-diagram 5. Budsjett for fasen Anbefaling om videre arbeid Med utgangspunkt i prosjektresultatene utarbeides en anbefaling for om prosjektet skal gjennomføres eller ikke og om eventuell strategi for gjennomføring Metoder og teknikker i forstudiet Arbeidet i forstudiet er, som vi tidligere har vært inne på, i stor grad preget av å få frem informasjon og skaffe seg forståelse av behov og muligheter. Det er en myk eller menneskeorientert fase hvor kreativitet og kommunikasjon har en stor plass. Dette har selvfølgelig betydning for hvilke metoder og teknikker som er aktuelle å bruke i denne fasen av prosjektet. Her er en stikkordsliste over noen aktuelle metoder og teknikker. Nærmer beskrivelse av noen av disse har vi tatt med i dette faget, andre finnes i litteraturen for de som er interessert i gå nærmere inn i metodikken : - Alle kreative teknikker, for eksempel Brain-storming side 15 av 17

16 - Forandringsanalyse - Workshop og arbeidsseminar, av og til kalt intensive arbeidsmøter - Intervjuer - Gjennomgang av eksisterende dokumentasjon - Enkle modeller av funksjoner og data i det området prosjektet skal arbeide med, kan være: DFD- diagram, OO-modeller, ER-modeller - Metoder for kost/nytte-analyser - Metoder for risikoanalyser 1.4. Referanser Innholdet i leksjonen bygger på et internkurs i ledelse av systemutviklingsprosjekter holdt for Statoils IT-avdeling gjennom en årrekke og hvor forfatter av leksjonen har vært en av kursholderne. Ellers kan utdypende lesning om emnet være: Tore Berg Hansen, Greta Hjertø: Kvalitet og programvareutvikling Erling S. Andersen: Systemutvikling Barry W Boehm: Software Risk Management: Principles and practises. side 16 av 17

17 1.5. Innhold 1.1. OVERSIKT OVER FORSTUDIEFASEN Hva er grunnlaget for å starte et forstudium? De viktigste oppgavene i forstudiet Viktige for å lykkes med et forstudium Oversikt over resultatene av forstudiet NÆRMERE OM DE VIKTIGSTE RESULTATENE AV FORSTUDIET Dagens situasjon - bakgrunn for prosjektet Prosjektmål Konsekvenser for organisasjonen Rammebetingelser Kritiske suksessfaktorer Risikoanalyse Forslag til prosjektorganisasjon Retningslinjer og standarder Aktivitets og ressursplan Anbefaling om videre arbeid METODER OG TEKNIKKER I FORSTUDIET REFERANSER INNHOLD side 17 av 17