LØSNINGSFORSLAG ØVING 6 Oppgave a Prosjektinterne kriterier for suksess. Litteraturen har ingen entydig og felles definisjon av prosjektsuksess. Fra prosjektets side har man tradisjonelt fokusert på følgende faktorer; -Tidsplan -Budsjett -Spesifikasjoner og ytelse. Prosjekter gjennomført i samsvar med tidsplan, budsjett og spesifikasjoner ansees som vellykkede. Dette gjenspeiles også i prosjektets formelle styringssystem som fokuserer sterkt på disse faktorene. Hva som skjedde etter at prosjektresultatet var ferdig, spilte mindre rolle. Senere begynte man også å vurdere faktorer som f.eks hadde med personell og kompetanseutvikling å gjøre. Prosjekteksterne kriterier for suksess Etter hvert ble det klart over at suksessbegrepet var mer sammensatt enn dette. Det var ikke vanskelig å finne prosjekter gjennomført i samsvar med kriteriene overfor, men som likevel var en fiasko. Likeledes kunne man trekke fram prosjekteksempler som viste det motsatte. I første omgang utvidet man suksessbegrepet til også å omfatte kundens eller brukerens tilfredshet og velferd (behovene antok man var dekket gjennom oppfyllelsen av spesifikasjonene). Det medførte en vektlegging av implementeringen av prosjektresultatet hos kunden. En vellykket implementering av prosjektresultatet avhang bl.a av; -Teknisk validitet, dvs om prosjektresultatet rent teknisk fungerte som forutsatt og skapte de forventede resultater, både som frittstående løsning og som integrert del av kundens øvrige systemer. -Organisatorisk validitet, dvs om prosjektresultatet var "det rette" for brukerne, hvor tilfredse brukerne var med resultatet og om de kom til å anvende det. -Organisatorisk effektivitet, dvs om prosjektresultatet var med på å forbedre kundens evne til å nå egne mål (økt effektivitet). Diskusjonen stoppet ikke her. Var det andre interessenter som avgjorde/påvirket om prosjektet ble en suksess eller ikke? Blant de interessenter som har blitt trukket fram, er de viktigste; -Basisorganisasjonen, dvs i hvilken grad prosjektets gjennomføring og resultat gav positive ringvirkninger for dens videre drift og utvikling. -Samfunnet generelt, dvs hvordan samfunnet stilte seg til ringvirkningene av gjennomføring og konsekvenser knyttet til resultatet. Konklusjonen ble at suksess bestemmes av både interne og eksterne faktorer. De interne har prosjektet direkte styring med mens de eksterne har prosjektet liten eller ingen innflytelse over. Suksessvurderinger over prosjektets livssyklus Resultatet av vurderingene om prosjektet var en suksess eller ikke, viste seg å avhenge av hvor i livssyklusen de ble foretatt. Prosjekter som var vurdert som en fiasko i startfasen, ble etter lengre tids bruk betraktet som en suksess og vica verca. Mulige vurderingstidspunkt var f.eks; -Under gjennomføringen av prosjektet -Ved overleveringen av prosjektresultatet (manualer) -Etter at opplæring og igangkjøring var avsluttet (serviceavtaler) -Etter en periode med stabil drift -Etter ombygging/modifisering/modernisering av prosjektresultatet. -Etter av beslutningen om utfasing er fattet. Fra prosjektets side var det mest interessant å vurdere gjennomføring og overlevering. Etter at resultatene var overlevert, opphørte prosjektets ansvar (om ikke annet så fordi prosjektet ble avviklet).
Fra basisorganisasjonens synsvinkel bør ikke disse vurderingene komme for sent etter overlevering. Jo lengre tiden går, jo mer sannsynlig er det at den generelle utvikling i samfunnet og interne forhold hos kunden vil påvirke vurderingen av prosjektresultatet. Dette kan være forhold som ligger langt utenfor det man med rimelighet kunne forlange at prosjektet skulle ta hensyn til. Fra kundens side er både vurderingen av selve prosjektets gjennomføring og de langsiktige konsekvensene av resultatet interessante. Dette viser hvor vi ktig det er at man blir enige om felles vurderingsskalaer for suksess samt om når disse vurderingene skal foregå. Dette er spesielt viktig for prosjektpersonellet som vil bli vurdert ut fra de oppnådde resultat. En ufullstendig eller feilaktig vurdering kan få betydelige konsekvenser, f.eks karrieremessig. Konklusjon: Det å bedømme suksess kun ut fra prosjektinterne faktorer knyttet til selve gjennomføringen, er en for snever betraktningsmåte. De faktorene som er nevnt i påstanden, vil derfor ikke være dekkende. Derimot vil de utgjøre en del av et mer omfattende suksessbegrep slik det er diskutert overfor. Oppgave 2b Når prosjektet defineres som opprettet, er her et viktig spørsmål. Alt etter hvem sitt synspunkt som legges til grunn, kan prosjektet opprettes når ideen unnfanges, når ideen er valgt ut for videreføring, når planleggingen er sluttført eller når kontraktene settes ut. Jeg legger en formell definisjon til grunn; Prosjektet er opprettet når det er formelt godkjent og når man har forpliktet tid og ressurser til gjennomføringen. Det betyr ikke at prosjektets er bemannet men at de overordnede forholdene er lagt til rette for rekruttering og utvelgelse av prosjektpersonell. Et annet moment som bør avklares, er hva som menes med suksesskriterier. Det sentrale her, er at det ikke finnes ett kriterium, men flere innen ulike områder som; 1. Gjennomføringskriterier, dvs kriterier knyttet til prosjektoppgaven og hvordan denne gjennomføres. 2. Brukskriterier, dvs kriterier knyttet til brukerens oppfatning av prosjektresultatet og hvordan dette fungerer i praktisk bruk. 3. Effektkriterier, dvs kriterier knyttet til hvilke effekter prosjektresultatet har for oppdragsgivers måloppnåelse. Det er flere argumenter som taler for at slike kriterier bør fastlegges før prosjektet opprettes. Blant disse kan nevnes; Harmonisering av ønsker, forventninger, krav og behov. Som det framgår av klassifiseringen av kriteriene overfor, kan prosjektet involvere flere aktører. Disse kan operere med hver sine ønsker, forventninger, krav og behov som de forventer at prosjektet skal ivareta. Bare unntaksvis er prosjektet i stand til dette, i hvert fall hvis det opererer innen stramme tids- org ressursrammer. En harmonisering av ønsker, forventninger, krav og behov innebærer i realiteten både en diskusjon om hva de inneholder, hvilke konsekvenser de medfører og en prioritering mellom dem. En slik harmonisering gir både mer "realistiske" og mer samordnede suksesskriterier, suksesskriterier det er enighet om at prosjektet skal oppfylle. Det burde være selvsagt at jo tidligere denne harmoniseringen foregår, jo bedre grunnlag er det for målsetting og planlegging av prosjektet i samsvar med kriteriene. Prosjektutvelgelsen. Det at et prosjektforslag velges ut framfor et annet, vil alltid være en relativ vurdering som bygger på mer eller mindre klare kriterier. Har man avklart prosjektets suksesskriterier på forhånd, blir det enklere å vurdere dem i forhold til utvelgelseskriteriene. Dette forutsetter selvfølgelig at organisasjonen premierer klarhet og entydighet framfor tåke og ikke etterprøvbare intensjoner ved utvelgelsen. Dessuten vil dette gjøre det vanskeligere å komme i ettertid med helt andre kriterier og kursvalg enn de som ble lagt til grunn ved utvelgelsen, noe spesielt en basisorganisasjon vil være opptatt av.
Mål og planer. Hvordan tar man hensyn til suksesskriterier hvis de ikke er avklarte før etter at mål og planer er fastlagte? Får de ikke konsekvenser for mål og planer, har det egentlig lite for seg å definere slike kriterier. Man kan selvfølgelig behandle dem som frittstående kriterier, men med de erfaringer en har med å behandle kvalitetskriterier på denne måten, er dette en lite fristende løsning. Forhistoriens innvirkning. Det er uheldig å vente for lenge. Etter hvert som prosjektet gjennomføres, fattes det en rekke beslutninger som definerer sentrale veivalg. Etableres det så suksesskriterier som stiller spørsmålstegn ved disse veivalgene, må man enten gjøre endringer i det som allerede er gjort eller ignorere kriteriene og fortsette som før. Det finnes en god del empiri på at slike kriterier enten oversees eller fortolkes på en slik måte at de skaper minst mulig internt bry for prosjektet. På den andre siden skal man også være åpne for endringer under veis. Det tar tid mellom når kriteriene fastlegges og når man skal vurdere gjennomføring og resultat i forhold til disse. I mellomtiden kan det ha skjedd en god del som gjør de opprinnelige kriteriene mangelfulle eller mindre aktuelle. Da kan absolutte kriterier bli mer en hemsko enn et hjelpemiddel til å skape et godt resultat. Kunnskapsendringer. Prosjektets suksess avgjøres av en rekke tildels komplekse kriterier som bare delvis er kjente ved oppstart. Etter hvert som man får større innsikt i og høster erfaringer med problemstillingen, kan både kriterienes innhold og gjensidige prioritering, endres. Oppdragsgiver ønsker som regel at prosjektet skal gjennomføres fordi han mangler kompetanse eller kapasitet til å gjøre det selv. Det betyr som regel at vedkommende har begrenset innsikt i problemstillingen og dens konsekvenser. Etter hvert som man får mer innsikt og kompetanse, kan dette bety at man endrer oppfatning av hva som er de mest sentrale sukesskriteriene. Da må det også finnes muligheter for å gjennomføre endringer. Situasjonsendringer. Verden står ikke stille mens prosjektet gjennomføres. Endringer i situasjon og omgivelser kan ha en betydelig innvirkning på hva som er relevante suksesskriterier. Man bør derfor være åpen for at disse kan endres under veis. Dette gjøres bl.a. gjennom egne organer for endringshåndtering som skal ivareta både behovet for endringer og behovet for stabil gjennomføring av prosjektet. Dette medfører i praksis en rekke avveininger, og dette arbeidet blir enklere hvis man er enige om suksesskriteriene, både de opprinnelige og de nye man ønsker å legge til grunn. Det finnes få gode grunner til å vente med utarbeidelsen av suksesskriteriene til etter at prosjektet er opprettet. Derimot kan det godt hende at kriteriene kan og bør endres etter hvert som man gjennomfører prosjektet. Noen av disse argumentene er gitt overfor. Aktørene bør derfor, i forbindelse med at de utarbeider og godkjenner kriteriene, også vedta retningslinjer for når og hvordan kriteriene kan endres under veis. Dette betyr imidlertid ikke at det bør forekomme hyppige endringer av disse kriteriene. Som regel bør man prøve å holde dem stabile, men er det umulige å oppfylle eller er de ikke hensiktsmessige i nåværende form, bør de være mulige å endre. Oppgave 2c Når man skal angripe denne oppgaven, er det en del forutsetninger og fallgruver ; 1. Begrepet integrert informasjonssystem er meget omfattende. I sin ytterste konsekvens kan dette omfatte alle formelle og uformelle objekter, relasjoner og prosesser som er knyttet til skaping, fortolkning, formidling og lagring av informasjon. Andre velger å avgrense begrepet til EDB-baserte beslutningsstøttesystemer. Du må avklare med oppdragsgiver hva vedkommende egentlig har behov for samt hvilke konsekvenser systemet vil ha for andre aktiviteter og prosesser. 2. At oppdragsgiver har lite erfaring med denne typen systemer, kan bli et problem, men trenger ikke bli det. Fordelen er at vedkommende verken er opphengt i gårsdagens løsninger eller har fasttømret og gjerne feilaktige oppfatninger av hva som er mulighetene og begrensningene for slike systemer. Ulempen er at oppdragsgiver vil få problemer med å skrive en fullgode funksjonskrav allerede i starten av prosjektet. Du må forvente at forståelsen av problemstillingen vil utvikle seg under veis i prosjektet, noe som kan resultere i omfattende endringsarbeider. 3. At oppdragsgiver ikke kan sette av personell til å arbeide på heltid med prosjektet, kan bli et alvorlig problem. Problemet er spesielt stort hvis du ikke får noen faste samarbeidspartnere å
forholde deg til menn må skifte kontaktpersoner hver gang du tar kontakt for å avklare viktige problemer og utfordringer. Dette kan gi en meget fragmentert beslutningsprosess, og det kan være et signal om at dette prosjektet likevel ikke har den nødvendige støtte og prioritet. 4. Din oppdragsgiver driver med en utstrakt prosjektvirksomhet overfor eksterne kunder. Det er i utgangspunktet ingenting som skulle tilsi at disse opererer med identiske krav, ønsker, forventninger og behov overfor din oppdragsgiver. Du kan heller ikke anta at disse har identiske informasjonssystemer. Faktisk vet du heller ikke eksakt hvilke kunder din oppdragsgiver vil betjene i framtiden samt hvilke krav dette stiller til informasjonsflyt over organisasjons- og systemgrenser. Som konsulent er du helt avhengig av å få kontakt med en del sentrale kunder for å kunne forstå hvilke krav de stiller i dag og i morgen samt hvilke konsekvenser dette får for det informasjonssystemet du skal utvikle. Hvis ikke, blir det meget vanskelig å oppfylle forventningene til din oppdragsgiver. 5. Du kan ikke forvente at din oppdragsgiver har full oversikt over alle integrasjonsmessige problemer og utfordringer knyttet til utvikling, introduksjon og drift av dette nye systemet. Hvis du må forholde deg til ulike representanter for oppdragsgiver, vil de som regel ha ulike oppfatninger av de problemene som skal løses, prioriteringen mellom dem og konsekvensene knyttet til dem. Du må spesielt regne med utfordringer knyttet til identifisering, definering og håndtering av avhengigheter og relasjoner mellom det systemet du utvikler og resten av oppdragsgivers organisasjon. Disse relasjonene og avhengighetene omfatter ikke bare tekniske problemstillinger, men også administrative, organisatoriske, politiske og kanskje kulturelle. Du kan ikke forvente å finne ett kriterium som dekker samtlige involverte aktørers behov, ønsker, krav og forventninger. Vi skiller mellom ulike typer suksesskriterier; 1. Knyttet til selve gjennomføringen av prosjektoppgaven 2. Knyttet til bruken av prosjektresultatet 3. Knyttet til hvilken innvirkning resultatet får for kundens egen virksomhet og måloppnåelse. Det er flere ting du kan gjøre for å øke sannsynligheten for å etablere klare og entydige suksesskriterier for prosjektet; Harmonisering av forventninger og krav. Siden oppdragsgiver har lite erfaringer med denne typen systemer, øker sannsynligheten for at vedkommende stiller med urealistiske oppfatninger av behov, ønsker, krav og forventninger. Dette gjelder både til selve systemet og til arbeidet med å få det til å fungere i egen organisasjon. Det å foreta en grundig gjennomdrøfting av slike forhold, kan legge et godt og nødvendig grunnlag for det videre arbeidet. Kontrakt. Kontrakten skal definere spillereglene mellom deg og oppdragsgiver, herunder rettigheter og plikter. Husk at oppdragsgiver er spesialist på sin egen virksomhet mens du forhåpentligvis er spesialist innen din. En kontrakt som som forutsetter at alt er avklart på forhånd og som skaper avstand, både når det gjelder sak og relasjon, vil skape betydelige problemer på et senere tidspunkt. Et godt slutt resultat avhenger av et godt samarbeid med god dialog og vilje til læring. Sannsynligheten for endringer i forhold til opprinnelige forutsetninger og funksjonskrav, er stor. I denne situasjonen blir det viktig å få definert kundens forpliktelser overfor prosjektet utover de klassiske rammebetingelsene. Du vil være spesielt avhengig av å få etablert effektivt fungerende beslutningsorganer samt mekanismer for håndtering av endringsforslag og deres konsekvenser. Etablere kontaktnett og tilbakemeldingsmekanismer. Siden oppdragsgiver ikke vil sette av personell til å arbeide på heltid med prosjektet, blir det meget viktig for deg å etablere et vidt og godt fungerende nettverk som kan gi deg de nødvendige opplysninger for å etablere et forslag til suksesskriterier. Dette gjelder både internt hos oppdragsgiver, hos vedkommendes samarbeidspartnere og overfor andre ressursinstanser som kan være relevante. Dette forslaget mår så godkjennes av personer og/eller organer hos oppdragsgiver som har autoritet til å fatte denne typen beslutninger og makt til å påse at de blir etterlevd. Slike beslutninger bør så raskt som mulig arbeides inn i prosjektets mål, planer og rammebetingelser. Dessuten er det av avgjørende betydning at de ivolverte aktørene forstår konsekvensene av disse kriteriene og er i stand til å følge dem opp gjennom sine bidrag til prosjektets gjennomføring og sluttresultat.