I og med at de fleste eGovernment-prosjekt faktisk er mer eller mindre mislykket, er det et sterkt behov for risikovurdering og risikoreduserende tiltak.

I alminnelighet mener Heeks at jo tidligere risiki blir vurdert jo vanskeligere er det å finne og vurdere konkret den enkelte risiko, mens jo seinere risiki blir vurdert jo vanskeligere blir det å gjøre noe med den.

Kapitlet dreier seg hovedsakelig om hvordan risiki kan oppdages og gjøres noe med.

Heeks mener at risiki kan vurderes gjennom en gap-analyse mellom dagens realitet og det forventede resultat av det planlagte eGovernment-systemet. Jo større gap – jo større risiko. Han anbefaler da at det nedsettes arbeidsgrupper som arbeider konkret med mulighetene for å redusere gapet. Hvis driverne for å gjennomføre prosjektet er sterke nok, kan prosjektet likevel bli vellykket på tross av stort gap som medfører større risiko. Men hvis driverne er svake, skal det ikke store gap til før sjansene for å mislykkes blir store.

For å redusere sjansene for å mislykkes ved store gap, introduserer Heeks ZABC-metoden.
Z = Zap the project – Gi opp prosjektet
A = Alter the project – Forandre noen av de initielle parameter for å gjøre prosjektet mer gjennomførbart
B = Be selfish – Vær egoistisk. Dersom prosjektet ikke kan gis opp og heller ikke endres – fokuser på hva prosjektet kan gi deg av personlig vinning, for eksempel opplæring, ekspertise og erfaring, penger eller utstyr
C = Change your job – Skift jobb

Resten av kapitlet fokuserer på å forandre prosjektet gjennom risikoreduserende tiltak.

Det finnes to hovedveier: Enten forandre det planlagte eGovernment-prosjektet til å ligne mer på dagens realiteter. Eller å endre dagens realiteter til å ligne mer på det planlagte eGovernment-prosjektet.

Heeks poengterer også at prosjekter med store gap kan medføre større fordeler for organisasjonen. Derfor må man gjøre en avveining mellom det å redusere gapet og det å redusere de organisasjonsmessige fordelene det nye systemet kan ha.

Deretter går Heeks inn på alternative teknikker for å redusere gapet. Noen stikkord:

·         Du må forstå dagens virkelighet

·         Du kan vurdere om standardløsninger kan tilpasses

·         Du bør vurdere å involvere ekstern leverandør sterkere

·         Du bør vurdere å modularisere løsningen og utvikle og implementere modulene gradvis

·         Du bør vurdere å engasjere personer som kan ha ”en fot i IT-leiren og en fot i forretningsprosessene/organisasjonen.”

·         Du bør forenkle mest mulig og ikke gape over for mye på en gang

·         Fokuser først på å forbedre prosessene, så ikke du implementerer ”dårlige prosesser”

·         Fokuser på å støtte opp under virkeligheten – virkelige behov

·         Støtt opp under uformelle informasjonssystemer og strukturer (sosiale nettverk)

Det neste Heeks går inn på er å adressere interessenters mål og verdier. For at et nytt system skal lykkes er det essensielt at sentrale interessenter er positive til systemet. Og da er det nødvendig at systemet innfrir i det minste noen av disses personlige mål og verdier.
”What’s in it for me” vil være en sentral spørsmålsstilling. Dette har vist seg å være en av de sterkeste faktorene for suksess eller ikke. Dette må adresseres og tiltak må gjøres for å bringe det i balanse. Heeks lister opp følgende mulige tiltak:

·         Belønning/Gulrot inkl. støtte fra viktige personer, attraktive kurs, ny tittel, involvering i utviklingen

·         God kommunikasjon om både positive og negative sider

·         Deltakelse i systemutviklingen

·         Mer aktiv deltakelse for å bygge konsensus

·         Prototyping (iterativ utvikling)

·         Brukerinvolvering og sluttbrukermedvirkning

Heeks avslutter med å si at selv om et prosjekt mislykkes, betyr ikke det at det ikke har ført til noe positivt. Det kan ha skjedd mange positive elementer av læring også i mislykkede prosjekter.

Etter å ha vært gjennom de to første kursdagene og reflektert over innholdet, tenker jeg: Det er da egentlig ikke så komplisert? Eller er det det likevel? Det dreier seg om relativt enkle prinsipp og grep. Interessentanalyse – kartlegging av AS-IS – Beskrivelse av TO-BE  osv. Men dog likevel så vanskelig å gjennomføre på en god måte? Hvorfor?

Er det fordi vi i kartleggingsfasen ikke får med oss hva mennesker opplever som verdifullt for dem? Forteller ikke de impliserte at når de skal utføre denne arbeidsoppgaven, så hører det f.eks. med at de går innom en kollega, tar en kopp kaffe og får nyttig informasjon samtidig som de får et 5-minutts atspredelse fra hektiske arbeidsoppgaver? Faller dette bort får det konsekvenser for noe annet. Er det intervjueren som er for lite flink til å spørre hva som betyr noe for den enkelte i den arbeidsprosessen som kartlegges? Eller er det kartleggingsmetodene og symbolikken som ikke klarer å fange det opp, så det forsvinner på veien? Eller er det markedsføringen av det nye som svikter? Er det ingen “entusiaster” blant brukerne som er med?

Uansett så er jeg overbevist om at den menneskelige faktoren her spiller inn i atskillig større grad enn den teknologiske. 

Jeg er overbevist om at vi mennesker har en tendens til, i de fleste tilfeller, å beslutte ut fra følelser mer enn kalde fakta. Vi lar følelsene styre oss – deretter velger vi argumenter som bygger opp under det vi har bestemt oss for å mene. Hos mange tror jeg dette er ganske ubevisst. Mange vil helt sikkert hevde at de tar beslutninger helt rasjonelt uavhengig av følelser. Noen kan sikkert være slik, men de fleste er det ikke. det er min overbevisning. Vi bør heller forholde oss til dette og spille på lag med at så urasjonelle er vi mennesker. Erkjenner vi dette og legger inn dertil egnede tiltak, så er sjansene til å lykkes atskillig større.

Nå skal jeg begynne å lese litteraturen. (Jeg bestilte Heeks på Amazon, og venter fortsatt på den ….

Ser frem med skrekkblandet fryd til både oppgave og neste samling!

God jul til alle!