Ole ØstergaardOplevet projektsucces er en mangeartet størrelse.

HerbertNathan & Co er i årenes løb stødt på både større og mindre projektopgaver, hvor det at opnå de umiddelbare resultatmål ikke nødvendigvis har afstedkommet det, man vil kalde en succesoplevelse.

Omvendt har vi også oplevet, at virksomheder har været meget tilfredse med resultatet af deres IT projekter, hvor slutleverancen ikke nødvendigvis ramte det eller de oprindelige mål for projektet.

Et af de redskaber, der ligger som en del af best-practice af enhver professionel anskaffelse, er business-casen. Spørgsmålet er, om business-casen kan være et af de omdrejningspunkter, der sikrer en mere ensartet oplevelse af, hvorvidt projektleverancer er succesfulde, og om vi ofte glemmer at bruge den aktivt undervejs i leverancerne?

Business-casens formål er at sikre, at der forud for en opgave / et projekts påbegyndelse tilvejebringes en så vidt muligt faktabaseret forventning om, hvad opgavens / projektets omkostninger er, og hvad forventningen til tilbagebetaling er – med andre ord hvad vi får for de penge vi investerer og med hvilken horisont, vi forventer at høste gevinsterne.

Det vil sige, at hovedindholdet samler sig om overskrifter som ’begrundelser for anskaffelse/igangsætning’, ’forretningsmuligheder’, ’forventet udbytte (positivt/negativt)’, ’tidshorisont’, ’omkostninger’, ’investeringsvurderinger’, ’risici’ og ’beregnet tilbagebetalingshorisont’.

De forventede forretningsmuligheder eller gevinster kan være af forskellig type lige fra de mere håndfaste økonomiske betragtninger, opnåelse af rationaliseringer, øget medarbejder- og kundetilfredshed, gennemsigtighed i forretningen, bedre styring mv.

Sagen er måske, at man i projekter og leveranceopgaver ofte har stor fokus på at styre ændringshåndtering af leverancegrundlaget (kontrakt, udviklingspunkter, procesændringer) for at sikre, løbende forventningsafstemning af indhold, økonomi og leveringstider (projektplaner). Samtidig er vi erfaringsmæssigt knapt så tilbøjelige til at huske at konsekvensstyre ændringerne over mod business-casen.

Det kan over tid i projektet skabe en helt skæv forventning til de forretningsmæssige resultater af projektet og dermed være med til at fordreje opfattelsen af, hvorvidt mål nås eller ikke nås.

Et helt konkret tænkt eksempel: I business-casen for et ERP-anskaffelsesprojekt havde man forudsat en række automatiseringer inden for en given produktionsenhed X. Automatiseringerne skulle realiseres gennem systemtilpasninger. På den baggrund indregnede man en betydelig rationaliseringsgevinst i business-casen for projektet.

Undervejs i projektet blev der i dialog med IT-organisationen på kundesiden truffet en beslutning om i så vid udstrækning som muligt at anvende standardfunktionalitet. Det var der en række IT-driftsmæssige fordele ved – herunder forventelige besparelser på vedligeholdelsen. En del af tilpasningerne i produktionsenhed X blev på den baggrund skåret bort, uden nogen fik taget stilling til, om de forventede besparelser gennem tilpasningerne nu kunne hentes hjem.

På et langt senere tidspunkt i forbindelse med den første drift står det klart, at det ikke er muligt at automatisere i så høj grad, som man har forudsat i business-casen, og projekt og system bliver i den nævnte produktionsenhed stemplet som en fejlinvestering.

Var beslutningen om at skære tilpasninger væk og satse på standardfunktionalitet forkert?

Det afhænger nok af øjnene, der ser, men der er ingen tvivl om, at ændringshåndtering af business-casen som et led i beslutningsprocessen for større ændringer i et systemanskaffelsesprojekt er en god praksis for at sikre højere grad af fælles oplevet succes/fiasko.

Helt lavpraktisk vil det være en god procedure at fremlægge ændringerne i business-casen på højeste ledelsesniveau, hver gang en projektændring har mulige konsekvenser for det forventede udbytte.