Er “prosjekt” alltid riktig verktøy?
Alle er opptatt av digitalisering. Alle er også opptatt av innovasjon. Disse to begrepene er ofte sammenfallende, men ikke alltid. Det er fremdeles tilfeller der digitalisering ikke krever noe særlig nyskapning – oppgaven går i hovedsak ut på å automatisere eksisterende prosesser.
Det vi vil stille spørsmål ved i denne artikkelen er om prosjektet er riktige valg av verktøy for alle digitaliseringsinitiativene. Er det slik at alt må angripes med det samme verktøyet? Hvor godt kan egentlig resultatet bli om verktøyet er det samme hver gang?
Bruk prosjekt der det passer
Prosjektet er en arbeidsform der en midlertidig prosjektorganisasjon får mandat til å gjennomføre en oppgave og å levere et konkret resultat som er definert på forhånd. Dette resultatet går deretter over i en drift- eller vedlikeholdsfase. Eventuelle endringer underveis skal gjennom endringsbehandling der endringen estimeres, vurderes og dokumenteres. En helt fin form for organisering, under visse forutsetninger, der det finnes mye erfaring og en rekke rammeverk og modeller man kan følge. I offentlig sektor har man valgt Prince2 og utarbeidet Prosjektveiviseren som er basert på dette rammeverket. Dette kan fungere godt der det skal gjennomføres en anskaffelse som er veldefinert og der usikkerheten er liten. Og om hovedhensikten er å lage en teknologisk plattform for å støtte en virksomhet, kan man gjerne supplere med virksomhetsarkitektur og TOGAF. Disse rammeverkene er basert på samme grunntanken og fungerer fint så lenge ting er forutsigbart og det blir kun få endringer underveis.
En mer rikholdig verktøykasse
Norsk offentlig og privat sektor behøver en rikholdig verktøykasse som inneholder mer enn prosjektstyring for sine digitaliseringsbestrebelser.
Selv om du er god med hammeren er det ikke lurt å bruke den til alt mulig
Med innovative anskaffelser forstår vi anskaffelser med en ganske stor grad av nytenkning og nyskapning. Man skal med andre ord gjøre noe som ikke er gjort før. Lage noe som ikke er lagd før. Er det fornuftig å betrakte slikt som en anskaffelse og et prosjektstyringsproblem? Vi har dyrekjøpt erfaring som viser at prosjekter med stor usikkerhet fører galt av sted. Det blir rett og slett for mange, for dyre endringer underveis – noe som igjen fører til forsinkelser og galopperende kostnader. Det neste som skjer er at man forsøker å ta igjen det tapte gjennom å “jobbe fortere” hvilket fører til dårlig håndverk. Dårlig håndtverk materialiserer seg ikke nødvendigvis i feil og mangler, men ofte gjennom dårlig vedlikeholdsvennlighet. Utviklerne har ikke tid til å rydde i koden og den utvikler seg til en uoversiktelig spaghetti. Tyngre og tyngre å jobbe med. Dessuten vil denne arbeidsformen invitere til at man låser seg i tidlig fase som igjen gjør det vanskelig å utnytte lærdom man vinner underveis.
Verktøykassa for innovasjon
Innovasjon bør som regel angripes iterativt, slik at det blir lettere å utnytte lærdom underveis. Vi må starte med å erkjenne usikkerheten og unngå å låse oss til antagelser. I stedet forsøker vi å utnytte iterasjonene til å validere antagelser slik at vi står på litt tryggere grunn.
Riktig verktøy for oppgaven
En slik iterativ, utprøvende tilnærming er i konflikt med prosjektet slik vi kjenner det. De som forsøker å gjennomføre prosjekter med et fast omfang og mange låste beslutninger i starten, vil nesten garantert gå på en solid smell med galopperende kostnader og forsinkelser. Vi trenger altså et helt annet verktøy.
Vi trenger verktøy og metoder som tillater oss å starte raskere – å ta raskere, bedre beslutninger i oppstartsfasen. Vi trenger verktøy som kan holde flere opsjoner åpne til de er testet ut og validert. Vi trenger verktøy som legger opp til hyppige, små leveranser som vi lærer av. Vi trenger metoder og verktøy som er brukersentrerte og som i praksis setter brukerne i førersetet. Og vi trenger verktøy som legger opp til en mer løpende finansiering, der også investeringen blir basert på det vi lærer underveis. Slike verktøy bør ikke baseres på Prince2 eller på Prosjektveiviseren slik den fremstår i dag. Ikke en gang på prosjektet som arbeidsform. Nei, til dette trenger vi en tilnærming som starter med brukerens behov og som forutsetter korte iterasjoner med feedback som drivkraft. Dette er verktøy basert på Lean- og Smidig- tankegangen.
Et fremgangsmåte skreddersydd for innovasjon og styring under usikkerhet
Iterativ oppstartsfase
Denne tilnærmingen vil kjøre oppstartsfasen iterativt. Her vil man teste ut både selve idéen og teknologiske valg. Det forutsettes at utviklere (i full tverrfaglighet) involveres tidlig. Metoder og verktøy for dette kan være Bygg-mål-lær (Lean Startup), Behov-Løsning-Test (BLT), Business Model Canvas, User Story Mapping, Impact Mapping, Design thinking og Scrum. For å nevne noen.
Iterativ planlegging og gjennomføring
Når oppstartsfasen (eventuelt) har gitt trygghet for at dette er verd å satse på, skaleres det opp og man iverksetter en løpende planleggingsprosess, en gjennomføringsprosess og en gevinstrealiseringsprosess. Alt dette kan baseres på Scrum, eller andre smidige, iterative rammeverk. Vi gjør her løpende kost/nytte-vurderinger som vil gi grunnlag for å beslutte når vi ikke klarer å tilføre nok ny verdi og det er riktig å stoppe opp og skalere ned igjen. Vi kan ikke på forhånd vite når et IT-system er ferdig utviklet, og det er fornuftig å se på dette som en vedvarende linjeoppgave. Ingen grunn til å skape en kunstig, midlertidig organisasjon når det er fullt mulig å gjøre jobben der hvor gevinstene skal skapes. Særlig når innovasjon basert på IT-utvikling er “Business As Usual”.
Iterativ finansiering og prioritering
Vi må akseptere at usikkerheten ikke tillater oss å øremerke midler med lang tidshorisont. Dette fører bare til at pengene blir brukt opp og målsetningene (kanskje) oppfylt selv om det i mellomtiden har dukket opp bedre, alternative muligheter. Offentlig finansiering bør snarest ta lærdom av Beyond Budgeting som blant annet legger opp til en mer løpende evaluering av hvilke satsinger som skal prioriteres. Risikoen reduseres og mulighetene for å lære underveis økes.
—-
Flere referanser om svakhetene med prosjekt i IT-utvikling.
BEKK Open: Slutt med IT-prosjekt
Miles blogg: Trenger vi egentlig prosjektledere?
Det smidige hjørne: Prosjektets tre problemområder
INFOQ: If you need to start a project you´ve already failed
Det er lett å finne flere referanser ved å søke på #noproject
In: inkrementell utvikling, ledelse, Planlegging, prosjektledelse · Tagged with: ledelse, organisasjon, prosjektstyring, Smidig, Styring