Når applausen i prosjektet har stilnet: Hva skjer etter at Smidigprosjektet er levert?

Fra Computerworld mars 2009:

Anne Kristine Næss er Cand.Polit med hovedfag i Sosialantropologi, og er seniorkonsulent i Avenir AS. Hun har erfaring som prosjektleder og endringsleder fra IT-prosjekter i offentlig sektor. For tiden jobber hun med innføring av leveransene av et stort, offentlig prosjekt som baserer seg på smidig systemutvikling. Anne Kristine er Avenirs fagansvarlige for gevinstrealisering.

I Computerworld 30.03.09 åpner Ahlert Hysing døra ytterligere på gløtt for smidig systemutvikling som nytt paradigme her til lands. Metoden, eller rettere sagt settet med gode praksiser, tar tak i mye av det som ikke har fungert i fossefallsprosjektene. Hysing beskriver noen utfordringer med fossefall og noen fordeler med Smidig, men lar tittelen ”Klappsalver for smidig” henge litt i lufta. Med mindre man leser artikkelen nøye, kan man tro at Smidig gir løsninger på alle fossefallsprosjektenes problemer. Det var kanskje ikke Hysings hensikt? I dette innlegget ønsker jeg å belyse noen forventninger det kan være skummelt for prosjekteiere og andre premissgivere å ha til Smidig – forventninger Smidiglitteraturen i liten grad selv tar mål av seg å innfri. De kan føre til like dårlige prosjektresultater og mangelfull gevinstrealisering som andre systemutviklingsmetoder til nå har gitt. For det er ikke nødvendigvis i systemutviklingsløpet de største feilene gjøres.


Fra behov til måloppnåelse

Mange aspekter ved systemutvikling påvirkes i overgangen fra fossefall til Smidig. Samlebåndsarbeid skiftes ut med tverrfaglige utviklingsteam, som gjennom dialog med kunden (her: produkteieren) forfiner behovene prosjektet springer ut fra. Beslutninger tas først når behovene er ferdig utdypet. Fokus på kontrakter og spillteori byttes ut med stor åpenhet rundt arbeid og fremdrift. Borte er den vrange kunden som ønsket rabatt, og inn trår en løsningsfokusert produkteier som fortløpende gir klarsignaler eller korrigerer kurs. Selvorganiserende utviklingsteam leverer potensielt implementerbar kode hver iterasjon (1-4 uker), uten at noen behøver å rasle med kontrakten. Det er altså mye god tenkning bak dette nye paradigmet.


Smidig utvikling løser behov istedenfor å tilfredsstille krav, hevder Hysing. Er det å løse behov det samme som å nå strategiske mål? I fossefallsprosjektene ble unødvendig funksjonalitet laget fordi kravene måtte skrives lenge før systemutviklingen og modningen av prosjektet startet. Men hva med produkteiere som lar seg forføre av alt utviklerne kan tilby av smart funksjonalitet underveis? Nye behov overskygger lett gamle og langt viktigere behov, eller fører til prosjektutvidelser. Hysing skriver også at ”Løsningen reflekterer ofte de mest taleføre og dominerende brukerrepresentantene” i fossefallsprosjektene. Blir dette bedre i smidige prosjekter? Kravspesifikasjonen i fossefallsprosjekter blir sendt på høring i organisasjonen, noe som gir diskusjoner og justeringer mellom brukergruppene. I Smidig justeres kravene i daglige eller impulsive stand up-møter, hvor alle har adgang til å lytte. Men de minst taleføre vet ikke alltid når det skal gjøres avklaringer som får betydning for deres behov, og må stole på en felles produkteier. En kollega av meg beskrev dennes dilemma: ”Tenk deg et systemverktøy som skal løse behovene på et sykehus: hvordan kan én produkteier gjøre rede for alle avdelingenes behov?” Og hvordan han eller hun skal prioritere mellom konkurrerende og motstridende behov gir ikke Smidig svar på.

Gevinstrealisering
Mye av årsaken til overskridelser i systemutviklingsprosjekter skyldes manglende evne eller vilje hos kunden til å fokusere på hvilke konkrete mål prosjektet skal bygge opp under, og hvordan måloppnåelsen skal måles og følges opp etter implementering. Smidig slår fast at alt man lager skal beskrives i form av hvilken nytte elementet skal kunne gi, men sier ikke hvordan ferdig utviklet funksjonalitet skal utløse gevinster. Metoden sier heller ikke noe om hvilke overordnede mål og strategier funksjonaliteten skal understøtte. Det er produkteieren som selv må foreta disse vurderingene. Man kan altså si at smidig systemutvikling minsker risikoen for at prosjektet fullstendig kaster bort tiden, men sikrer ikke at tiden brukes til å gi uttelling for investeringen.


Det er gledelig å se at smidig systemutvikling har tatt grep om mye av det som gjorde systemutviklingsjobben vanskelig. Desto mer synd er det når man glemmer at Smidigparadigmet regulerer og optimaliserer nettopp systemutviklingsløpet. Det å slutte fra at dette gjøres rasjonelt og hensiktsmessig til at behovene til systembrukerne faktisk dekkes i siste instans, er i beste fall naivt. Teknologien er kun ett av flere virkemidler for å dekke et behov. Man må i tillegg sørge for økt kompetanse, en organisasjon som legger til rette for bedre arbeidsprosesser, og ikke minst: en økt forståelse hos systembrukerne av hva som skal til for å skape verdier. Hva er våre primære mål? Er våre behov godt nok kartlagt før vi begynner? Kan vi dekke behovene våre gjennom å utnytte det vi allerede har på en bedre måte, i stedet for å starte nyutvikling? Hvordan sikrer vi at systemløsningen blir brukt etter hensikten? Dette har ikke Smidig noen teknikker eller praksiser som løser, like lite som fossefallsprosjektene hadde det. Så gå i gang med å etablere solide prosesser for gevinstrealisering først som sist. Jobb deg selv frem til svarene på disse spørsmålene, og tenk mer på det som skal skje etter at prosjektet er pakket sammen. Enten du ønsker å oppleve klappsalver underveis i systemutviklingsløpet eller la det skumme hvitt mellom fasene i et fossefall.