Richard Heeks, Sammendrag av kapittel 10: eGovernment Risk Assesment and Mitigation
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.
