eGovernment System Lifecycle and Project Assessment

Levetidssyklus.

Det er viktig å merke seg at system må utvikles ut fra og gjennom dynamiske prinsipper. Et system utvikles normalt gjennom ulike stadier og bør implementeres slik at det kan dekke ulike behov som vil kunne oppstå i virksomheten også etter utviklingsfasen. I utviklingen av systemer har det tradisjonelt vært vanlig å fokusere på 4 kjernefaser;

• analyse av behovet i nåtid
• design av systemets komponenter
• konstruksjon av systemet
• implementeringen

De aller fleste prosjekter vil forsøke å endre nåtiden. De vil slik sett bygge  den videre systemutviklingen på et gap mellom hva som er reell nåtid og hva som er “ønskesituasjon”. For å redusere dette gapet og i større grad sikre prosjektet er det derfor viktig å se på de tre aktiviteten;

• kartlegge realitetene i nåsituasjonen
• designe et forslag til en ny situasjon
• evaluere ulikheter og forskjeller mellom de to situasjonene og agere i forhold til disse

ITPOSMO sjekklisten er et godt verktøy for å granske hver enkelt av ulikhetene som er definert. Sjekklisten vil bidra i å forstå gapene i virkelighetsoppfatningen i forhold til designet.

Ved å integrere disse nye dimensjonene inn i de fire tidligere kjernefasene, men samtidig også legge inn en femte kjernefase vil vi få følgende kjernefaser for prosjekter;

• Prosjekt evaluering
• Analyse av nåtids virkelighet
• Design av en foreslått ny virkelighetssituasjon
• System konstruksjon
• Implementering og etterevaluering

Evaluering og riskreduksjon identifiseres som egen aktivitet som foregår på siden av de ulike fasene. Viktigst er å bruke risikostyring i forbindelse med punktene 1-3 og 5. Om vi nå ser på levesyklusen til et slikt system vil vi etter endt prosjekt kunne starte pånytt etter evalueringen av implementering. Vi vil her da avdekke hensiktsmessigheten til systemet, og kan definere nye prosjekter for endrede oppgaver. FIGUR 7.1 fra R. Heeks viser en modell av fasene i levesyklusen:

Utviklingsmetodikk.

En metodikk for system analyse og design er SSADM (Structured System Analysis and Design methodology). Denne modellen må brukes med varsomhet i forholdet til å ivareta organisasjonens  biologi. Det er viktig å velge utviklingsmetode ut fra omfang, virksomhetenes natur og utviklerenes holdninger. Derfor er det mer viktig enn å følge slavisk en metode å se på to viktige elementer;

• Reflektert utvalg av relevante individuelle teknikker for systemutvikling
• Sammensatt og blandet tilnærming til oppgaven som skal løses (hybrid tenkning)

Prosjektvurdering

Identisering og datainnsamling:

Denne fasen dreier seg om å analysere hvorvidt det er henisktmessig å starte prosjektet. Det er viktig å ha kjennskap til hvordan behov for utviklingsprosjekter kan oppstå. Det er viktig å også skille analysen på to vesentlige punkter. Det ene punktet er behov som adresseres utenfor organisasjonen, det andre er behov som er adressert og kanskje strategisk planlagt innenfor organisasjonen. Uansett hvordan behovene er oppstått må det likevel gjøres de samme aktiviteter i forkant av et prosjekt, mulighetvurdering, prioriteringer, ressursvrudering og sist men ikke minst en vurdering av hvordan prosjektet vil påvirke organisasjonen. I den videre datainnsamling og vurdering er det dog viktig å hensynta hvor behovet har oppstått. Interessentanalysen (stakeholdere) må vektlegges ulikt under de to punktene. TIdligere kapitler i boka har identifisert en rekke interessenter, se kap 5. Interessentene bør grupperes for å se hvordan de involveres i prosjektet og de ulike fasene. Problemformuleringen er viktig før oppstarten av prosjekter. En presis formulering gir tydeligere mål og bedre mulighet for å måle prosjektoppnåelsen. Et viktig spørsmål å stille underveis er hvorvidt det er et virkelig behov for prosjektet. En kost-nytte evaluering bør gjøres for å stille spørsmålstegn ved det virkelige behovet. I dette kan man også avdekke hvem som er de virkelige pådrivere av det definerte behovet, og slik sett oppnå en  bedre målbeskrivelse og evaluering av hensiktsmessigheten. Neste analyse som må gjennomføres er hvilke begrensninger ligger i prosjektet, både mandat og organisasjons og samfunnsmessige. Her kan ITPOSMO sjekklisten være et godt verktøy. Vurdering av eierskap, rollene og personellet som er involvert vil også naturlig høre hjemme her. Til sist i denne fasen kommer kanskje det vanskeligste – det å spå om framtida, både teknologisk og strukturelt. I eGovernmentprosjeketer må det også i stor grad hensyntas skiftninger i politisk grunnlag, bevilgninger av penger og ikke minst hvordan ivareta personellet i “den nye” organisasjonen.

CATWOE sjekkliste;

For potensielle prosjekter vil det være hensiktmessig å benytte sjekkliste for å oppsummere aspektet så rasjonelt som mulig. CATWOE står for Clients, Actors, Transformation, Worldview, Owner og Environment. Ved å benytte sjekklisten for de ulike aspektene som framkommer vil dette gi en oppsummering som lett kan diskuteres av flere ulike roller i og rundt organisasjonen. FIGUR 7.4 fra R. Heeks oppsummerer elementene i CATWOE sjekkliste

Vurdering av tjesteområdet

For å gjøre en vurdering av nåsituasjonsbeskrivelsen og det evnetuelle gapet til designbeskrivelse er det viktig å gjøre en analyse av tjenesteområdet, eller den aktiviten som skal dekkes av prosjektet. En gjennomførbarhetsanalyse vil være ett godt utgangspunkt for dette. For ikke å slite ut ITPOSMO sjekklisten kan vi her benytte PoTHOleS;

• Potitics – Politikk
• Technology – Teknologi
• Hard Cash - kontanter
• Other lesser resources – Andre mindre ressurser
• Sustainability – bærekraften (utholdenheten)

For hver av disse elementene kan vi stille oss ulike spørsmål i forhold til hvorvidt prosjektet vil holde mål. Vi kan ogsås ved å stille motspørsmål kunne få avdekket hindringer som til nå ikke er kjent for prosjektet. Alt i alt er dette en svært viktig aktivitet i vurderingen av oppstarten av et prosjekt. Videre prioriteringer vil måtte hensynta de konkrete fakta som er kommet på bordet i disse studiene. Videre kost/nyttevurdering innad vil også bygge i stor grad på resultatene fra forstudiet. Elementer fra den aktiviteten kan også benyttes inn i studien av hvordan prosjektet vil kunne påvirke organisasjonen eller dens omgivelser.

Prosjektplan og -ledelse

I den siste fasen før oppstart er det viktig å planlegge gjennomføringen av prosjektet. Grunnleggende spørsmål som;

• Hvordan
• Hvem
• Hva
• Når

må stilles og besvares i planen. Mange bruker ordet plan i forbindelse med ordet tidsskjema, men det er her viktig å ikke fokusere på tidsskjemaet altså spørsmålet om når, før de resterende grunnleggende spørsmål er besvart og bearbeidet til en plan. Viktig er det også å ikke overfokusere på teknologi eller IT, men heller la dette inngå som en normal fagaktivitet for å oppnå prosjektets mål.