Jeg viser til min artikkel Hvorfor offentlige IT-prosjekter feiler, og kommentarene til saken som peker i samme retning. Ut fra dette skal det her presenteres noen forslag – kall det gjerne en dreiebok – for IT-utvikling i offentlig regi.
Bestem dere for «smidig systemutvikling» og definer hva dere legger i dèt.
Dette begrepet kan defineres som å være en vanskelig kombinasjon av det å være både kreativ og disiplinert. Konkret betyr dette at representanter hos brukerne skal gjennom flere runder gå gjennom krav-spesifikasjonen, og være meget nøye med hva som egentlig bør være med i første runde. Deretter betyr metoden at under systemutviklingens gang skal bestilleren være meget lydhør for utviklerens både positive og ikke minst negative reaksjoner på utvidelsene – som alltid(!) vil komme. Dette innebærer særlig at bestilleren er nøye med utvidelser som ikke er skissert i første omgang. All erfaring tilsier at dette er en krevende øvelse – og vil fortsette å være under utviklingens gang!
Styringsgruppen
Dette er en sentral enhet i et utviklingsprosjekt, selv godt sammensatt garanterer den ikke et prosjekts suksess, men vil alltid være en krumtapp, på godt eller vondt. For å unngå det siste alternativet bør noen sentrale deltagere være:
- Lederen bør være forankret i etatens toppledelse, hun/han bør være sitt ansvar bevisst, dvs. ha avsatt tid for denne rollen.
- Det bør være minst to typer IT-spesialister i gruppen, den ene bør ha vidtgående erfaring i gjennomføring av store prosjekter, den andre bør ha teknologisk detalj-kompetanse minst på høyde med utviklerne
- Generelt bør øvrige deltagere så langt det er mulig ha ansvaret for sine delområder, de bør «eie» hvert sitt område, dvs. også «eie» eventuell problemer – jo større prosjekt jo flere delområder. Og ikke minst – de må ha tid!
Prosjekt-ledelsen, her konsentrert rundt bestillerens (den offentlige etaten) deltagere
Dette er en gruppe hvor samarbeids-ånden er av stor viktighet. I løpet av et prosjekts gang vil det være en ujevn strøm av problemer som må løses, de fleste vil som oftest være p.g.a. utilstrekkelig prosjekt-spesifikasjon – som utvides i rykk og napp. Dette vil bl.a. kreve at prosjektgruppens deltagere virkelig er sitt ansvar bevist, og at de som nevnt har tid. Et viktig prinsipp, som bør prioriteres fra begynnelsen av, er et felles ansvar for å skille mellom «nice-to-have» og «need-to-have». Det ugreie med dette er at under utviklingens gang vil det skje en vandring mellom disse to spesifikasjonene.
Dokumentasjon-standard
Velg helst et innarbeidet dokumentasjons-system, særlig inneholdende et meldingssystem for testresultater, feil-meldinger og for design-/spesifikasjons-utvidelser. Ikke tro et eneste øyeblikk at løpende dokumentasjon er lett – alle som har deltatt i systemutvikling vet at dokumentasjonen må vente litt rett som det er.
Styringsgruppen bør ha som absolutt ansvar for å påse at den besluttede dokumentasjonsstandard blir fulgt.
Innledende systemdesign og med eventuell pilot-løsning
Innledende system-spesifikasjon er ofte «ondets rot» ved problem-prosjekter. Erfaringen er at bestilleren har en noe vag forestilling om system-spesifikasjonen – på nivået under de rene honnør-formuleringene. For særlig de større prosjektene vil det nesten alltid være en god idè å utvikle en pilot – som er et skjelett-lignende system med noen av de viktigste egenskapene. Dette er ofte det viktigste hjelpemiddelet for å få frem detaljeringer og utvidelser av system-spesifikasjonen. Utført riktig kan en pilotløsning utvikles sømløst mot en første utgave av det fungerende systemet!
Møte-disiplin
Erfaringen er at bestillerens representanter ofte ikke har tid til å delta i møter, heller ikke være diskusjonspartner ved utviklers alle spørsmål. I slike tilfeller veltes ansvaret over på utvikleren, hvilket er et (kjent) faresignal. Her er styringsgruppens disiplinering sentral, uten inngripen er dette en potensiell kilde til alle former for uheldig utvikling.
Test-metodikk
Det er flere nivåer av testing og –metodikk. Hoveddelene er for det første utviklernes egne tester av egne rutiner, som bør dokumenteres! For det andre bør hoveddelen av testene, fra rutinenivå til hele system-tester, absolutt utføres av eksterne testere. Godt utført og dokumentert vil testene vær et godt hjelpemiddel både underveis og som grunnlag for akseptansetester. Utilfredsstillende utført er dette en av hovedårsakene til problemer.
System-revisjoner
System-revisjoner bør benyttes, ikke bare til oppsummering og oppdatering av systemets status, men også til gjennomgang av prosjekt-arbeidet og kontroll av at alle utfører det man har blitt enige om.
Du vet du har trøbbel når…
.. et eller flere av følgende punkter er til stede:
- Dårlig samarbeidsklima observeres
- Bestillernes representanter i prosjektet har ikke tid og/eller er lite engasjert
- Utilfredsstillende dokumentasjon av utvidelser i krav-spesifikasjonen
- Testingen er utilfredsstillende og/eller mangler skikkelig dokumentasjon
- Systemutviklingen er forsinket, uten noen påviselig grunn, tiden overskrides og prosjektet fordyres
- Et viktig delproblem er at en utvidelse av kravspesifikasjonen, som kan synes «ufarlig», medfører at systemets design går over fra å være hensiktsmessig til det motsatte (selvopplevd!). Her vil kniver slipes og hoder rulle.
- Til slutt – det viktigste av alt – styringsgruppen fungerer ikke etter hensikten, typisk blir da alle avgjørelser overlatt til utvikleren, mens bestilleren «lener seg tilbake» og håper på det beste – og slik vil det ikke gå!
Oppsummering
Disse punktene – denne dreieboken – inneholder i hovedsak selvfølgeligheter – det merkelige er at når alle disse offentlige IT utviklingsprosjektene feiler så er et flertall, eller ingen av disse selvfølgelige aksjons-punktene utført.