Sannheter, halvsannheter og prosjektstyring
Jeg har som de fleste gått igjennom en del faser i mitt arbeidsliv. Etter å ha vært programmerer ble jeg raskt prosjektleder, så metodeansvarlig, deretter var det prosessforbedring helt fram til i dag. Prosessforbedringen har også hatt faser. I begynnelsen lå det ferdige “oppskrifter” i bunn som ISO 9001 og CMM og CMMI. Deretter var det Goal-oriented-improvement som gjalt, og i de siste 10 årene har det vært “smidig prosessforbedring”. Det som slår meg er at i hver av disse fasene har jeg hatt helt ulike forklaringsmodeller både når ting går bra og dårlig.
Law of the Instrument og Retrospective Coherence
“Har du en hammer vil alt se ut som spiker” lyder et ordtak. I følge wikipedia var dette
først uttalt av Abraham Maslow i 1966 og blir ofte omtalt som Law of the Instrument
“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail”
Det slår meg at denne fella har jeg ubevisst gått i en rekke ganger opp i gjennom – mine mer eller mindre bastante konklusjoner har vært avhengig av min egen rolle og mitt eget fokus. Man betrakter verden gjennom helt spesielle briller. Jeg har alltid ivret for å lære av erfaring, og verdsetter objektivitet, men innser nå at dette er en svært krevende øvelse, spesielt om vi har å gjøre med komplekse systemer å gjøre! (Se også fotnote *)
Joseph Pelrine skriver om dette i sin blog post On Retrospective Coherence. Om vi har opplevd noe spesielt vellykket, er det da bare å gjenta dette til punkt og prikke? Pelrine skriver om et særdeles vellykket party. Om vi inviterer akkurat de samme gjestene, spiller den samme musikken og serverer de samme drinkene, vil vi da få en like vellykket fest? Nei selvsagt ikke nødvendigvis, i sosialt komplekse systemer er kausaliteten flyktig. Årsak-virkning forholdene utvikler mens individene interagerer med hverandre. Akkurat som innen software-utvikling! Så når vi i ettertid forsøker å resonnere om årsak og virkning, vil alle involverte lete etter svar innenfor sitt eget fokusområde – uansett hvor relevant det måtte være. En konsekvens av dette er jo at det ikke finnes noen såkalt “best practice” når vi holder på med komplekse oppgaver. I sedet må vi finne arbeidsformer som takler dynamikk og kompleksitet.
Som prosjektleder
Når jeg for mange år siden var prosjektleder i utviklingsprosjekter, jobbet jeg hardt for å bryte ned alle kravene, lage Work Breakdown Structures og milepælsplaner. Jeg sørget for å lage Gantt-diagrammer, innhente tidsestimater og synliggjøre kritisk linje. Deretter var det å analysere risiko og “massere” planen og kritisk linje slik at vi hadde godt tro på Planen. Jeg trodde fast og fullt på at prosjektets vellykkethet først og fremst ville være avhengig av godt forarbeid og av Planen. Og i etterkant av et godt prosjekt, i prosjektevalueringen, var det godt forarbeide og en god plan som ofte ble trukket fram som årsaken til suksess. Om prosjektet ikke gikk så bra, husker jeg godt å konkludere med at om vi bare hadde gjort grundigere forarbeide, og bedre planlegging ville det gått bra.
Som metodeansvarlig
Etter hvert ble jeg ansvarlig for metoder og verktøy for programvareutviklingen. Vi skulle følge Cleanroom Software Engineering og vi skulle være ISO-9001 sertifiserte. Fokus på den tiden var å etablere klare, veldefinerte prosesser. Dessuten måtte vi ha et utviklingsmiljø som i størst mulig grad var automatisert. Om vi klarte å gjøre prosessene brukervennlige, repeterbare og automatiserbare kom vi til å få suksess. Planen kunne da lages mye raskere, siden prosjektene “kom til dekket bord”. Og vi lyktes veldig bra med dette på Siemens Forsvarssystemer på 1990-tallet. Vi hadde hjelp fra forskere fra Sintef og andre steder og det ble til og med skrevet en dokoravhandling om prosessene våre. Når vi så klarte å kjøre et par prosjekter med stor grad av suksess, var det selvsagt de modne prosessmodellene våre som fikk æren.
Som prosessforbedrer
Etter hvert ble fagfeltet mitt prosessforbedring og jeg ble involvert i stadig flere forskningsprosjekter – og jeg var i den forbindelse med på en rekke prosjektevalueringer. Vi gjennomførte evalueringer (“Post Mortem analyser”) med stor innlevelse, og vi fant forbedringstiltak knyttet til planlegging og styring. Brukte vi CMM var forklaringen ofte lenger – det var mangel på “complience”, noe som selvsagt i beste fall var en grov forenkling. Det var mye som skurret hos meg på denne tiden. Var det virkelig sånn at en vel gjennomført plan var det samme som suksess? Jeg husker et prosjekt som var hårreisende dårlig gjennomført; Planen ble ikke fulgt, endringer ikke dokumentert og alle rammer sprengt. Evalueringen dømte det nord og ned. Men etter at produktet hadde vært i drift en tid, viste det seg at alle var strålende fornøyde! “Dette var verd alle overskridelsene” var omkvedet. Jeg husker også prosjekter som var kjørt helt forbilledlig, innenfor plan med all dokumentasjonen på plass. Evalueringen var positiv, men etter noe tid i drift var alle enige om at resultatet var elendig, bortimot ubrukelig.
Scrum er optimalisert for å kunne lære av erfaring. Når jeg i 2004 oppdaget dette, fikk jeg en slags oppvåkning. Det å jobbe i korte tidsbokser på 2-4 uker var med å på redusere kompleksiteten voldsomt. Når hver tidsboks var like lang, og det var de samme menneskene som gjorde jobben, fikk vi endelig en grad av repeterbarhet og kort tidshorisont, som gjorde det mulig å trekke noen konklusjoner av erfaringsmøtene. Fremdeles usikkert og vanskelig, men dette ga jo trygge omgivelser til å eksperimentere med prosessene på en måte de strore prosjektene bare kan glemme.
Prosjektsuksess?
Prosjektledere vil i henhold til Law of the Instrument og Cognitive Ressonance definere suksess innenfor de mentale modellene de bruker, med det språket de behersker. Man gransker verden med prosjektlederbriller på. Helt naturlig dette her. Og kunden og andre interessenter lytter selvsagt til prosjektlederne. Men dette gir selvsagt en farlig overforenklet analyse! Ett opplagt moment du mister på den måten er jo at du vil neglisjere vedlikeholdsvennligheten til systemet prosjektet etterlot seg. Vedlikeholdsvennligheten – eller “graden av teknisk gjeld” vil være vel så avgjørende for systemets nåverdi på lang sikt. Dette blir ikke målt i prosjekter og derfor neglisjert – og vi vet positivt at svært mange systemer i den offentlige forvaltning i dag er utsatt for store mengder teknisk gjeld. Det er lett å mistenke at arsaken ligger i at dette ikke får fokus når vi skal definere suksess.
Vi ser stadig at prosjektsuksess defineres som grad av budsjettoverskridelser og tidsoverskrivelser. Dette vil lett forføre kunder, økonomer, sjefer og andre interessenter (som sjelden forstår seg på programvareutvikling) til å tro at planene, prosjektstyring og prosessmodeller er det som virkelig teller.
For det første må vi anerkjenne at det er mange faktorer som er avgjørende og at vi må definere suksess i det rette tidsperspektivet, slik at vi får tilstrekkelig forkus på vedlikeholdbarhet. Dernest må vi snakke om gevinsten brukerne får av systemet og ikke av andre indirekte og irrelevante faktorer. Prosjektlederne og økonomene har alt for lenge fått definere suksess og dermed klart å dreie fokus vekk fra de mest avgjørende faktorene som gjelder i komplekse systemer. Suksess må måles i direkte realiserte gevinster, fornøydhet hos brukerne, vedlikeholdbarhet og hvor raskt endringer kan innføres.
Hva er egentlig avgjørende for suksess?
Alle som forstår seg på programvare og som har vært i bransjen en stund, vet at estimatene er ekstremt usikre, Planen er kun gyldig en liten stund og at vi til tross for grundig forarbeide er nødt til å improvisere en hel del underveis. Dette er helt normalt og helt OK i komplekse arbeidsoppgaver. Så, under slike forutsetninger, hva er det da vi må være gode på? Hvis det ikke er planlegging og prosjektstyring, hva er det da?
Så vidt jeg kan skjønne koker det ned til at vi setter klare effektmål, at de som gjør jobben er engasjerte, motiverte og kompetente, at disse får tillit og store fullmakter, samarbeider godt med brukerne, at vi klarer å dele opp produktleveransene i små delleveranser som evalueres fortløpende, at vi evner å lære av erfaring og at vi klarer å prioritere og sikre at vi bruker tid og krefter på det som virkelig betyr noe for brukerne.
Dette er i hvert fall min evaluering som smidigentusiast. Kanskje kommer det noe etter smidig, vi får se om jeg ser likt på dette i neste fase…
*) Oppdatering: Vår trang til å overforenkle er også forklart på en utmerket måte i boka Thinking, fast and slow av nobelprisvinner Daniel Kahneman. Han beskriver her fenomenet WYSIATI (What You See Is All There Is). Vi fokuserer intuitivt kun på det som er synlig for oss, og neglisjerer ubevisst andre faktorer – hvilket fører til overforenklede analyser når vi skal ta beslutninger.
In: ledelse, prosjektledelse, Samfunn, Scrum · Tagged with: kompleksitet, kundeverdi, ledelse, organisasjon, prosjektstyring, Scrum, Smidig