Sagt om estimering: “Estimation is the most optimistic prediction that has a non-zero probability of coming true” og “what is the earliest date by which you cannot prove you will not be finished” – Tom DeMarco (Mc Connell)

Estimering og kommunisering av planer er noe vi alle er kjent med. I det ene hjørtet står kunden og sponsoren som forventer en eksakt dato og prislapp. I motsatt hjørne står leverandøren og prosjektlederen og skal forsøke å gi en dato og pris.

Først et par påstander (og etter hvert virkemidler om de brukes riktig…)

1. Prosjekter er av natur ikke identiske. Egenskaper, forutsetninger og rammevilkår for prosjekter er forskjellig fra prosjekt til prosjekt. En rekke faktorer spiller inn: alt fra organisasjon, tilgang på kompetanse, teknologi, økonomi og en rekke andre rammevilkår. Med andre ord en rekke faktorer som ikke kan overføres fra prosjekt til prosjekt.
2. Prosjekter og spesielt utviklingsprosjekter er en læringsprosess. På ikke noe tidspunkt i et prosjekt vet prosjektdeltakerne mindre enn på prosjektets første dag. Og hvordan skal man da kunne svare kunden før i det hele tatt vet “noe som helst”?
3. Tall (matematikk) representerer noe faktisk, noe konkret og noe som er dokumentert. Vårt bevisste og ubevisste forhold til opplevelse av tall er medvirkende til at estimater, datoer og priser oppfattes som noe konkret. Utfordringen er ofte å kunne uttrykke usikkerhet med tall.

Tilbake til ringen hvor kunde og leverandør utfordrer hverandre. Kunden forventer at leverandøren skal gi gode estimater og bombesikre priser. Leverandøren på sin side kan bare i begrenset grad overføre erfaring (1) fra tidligere prosjekter, vet veldig lite (2) om prosjektet, og vil når det presenteres tall (3) bli oppfattet som konkret og derav bundet til disse.

En umulig oppgave?

Neida, her gjelder det å være bevisst på hva som egentlig skjer. Hele “konflikten” mellom mottaker og leverandør dreier seg om usikkerhet. Før et prosjekt har startet vet man veldig lite om 1 og 2 som gi må reflekteres i punkt 3. Gjør man ikke det, har man lagt grunnlaget for enten at prosjektet mislykkes eller at prosjektforløpet reduseres til en megling over kontrakter fremfor å være en kreativ utviklingsprosess til kundens beste. Altfor mange prosjekter, kunder og leverandører har feilet fordi man ikke håndterer risikoen som usikkerheten påfører prosjektet. Usikkerhet er ikke nødvendigvis risiko i seg selv om man takler dette rett!

Som leverandør gjelder det derfor å bevisstgjøre kunden om dette (og enda bedre: vica verca!). En god modell for å ta opp denne problemstillingen er usikkerhetsprinsippet, eller “the cone of unceirtanty”. Den illustrerer poenget rundt usikkerhet på en enkel måte. (Flere prosjektrammeverk refererer til denne modellen, blant annet PMI).

En forenklet forklaring av modellen:

1) Start med prosjektets siste dag. Det er først når man er ferdig at man vet hva prosjektet har kostet, hvor lang tid det har tatt og hva man har laget.
2) Går man “bakover” i tid, vil usikkerheten øke, men alltid for hver dag som går i prosjektet vite litt mer og dermed gradvis snevre seg inn mot “binært ferdig”. Et prosjekt blir bare forsinket en dag av gangen…
3) Går man til prosjektets første dag, vet man minst. Man har ikke engang begynt å jobbe med prosjektet. Hvordan skal man da kunne angi en tids- og kostnadsramme som treffer med 95 % sikkerhet?

Det er 3 hovedpoenger med denne modellen:

a) man må alltid utføre noe arbeid for å redusere usikkerhet (man beveger seg kun fremover dersom man jobber med det – et estimat blir ikke mer eksakt om man lar det ligge til neste uke…). Man er nødt til å kjøre forprosjekt, analyser, kartlegginger, proof-of-concepts for å vite litt mer og dermed kunne redusere usikkerheten for hva tids- og kostnadsrammen vil bli. 
b) Usikkerheten reduseres ikke gjennom ytterligere estimering. Kun gjennom å samle data, bygge erfaring og reflektere rundt arbeid utført opp i mot opprinnelige estimater, samt fjerne variasjoner og kontrollere endringer (ta beslutninger, etablere et stabilt prosjektteam etc.) kan man gradvis fjerne usikkerheten. 
c) hvordan skal man før prosjektet starter (eller gi tilbud?) uttrykke det store spranget som estimatet vil være? Dersom du skal være 95 % sikker på at du treffer må estimatet dekke et meget stort sprang, fra minste til øverste ramme.

Dette siste punktet bringer oss over i talls klare og uklare tale og om hvordan man skal bruke tall til å utrykke usikkerhet. La oss først starte med å se på noen tall- og estimeringseksempler:

For å oppsummere så er det viktig at man er bevisst i “estimeringsøyeblikket”. Man må være bevisst på den usikkerheten som vil være tilstede og ikke tro at man kan spå i fremtiden. Man må videre være bevisst på hvordan man kommuniserer usikkerheten i estimater og i tilbud.

Sett opp i mot en smidig prosjektgjennomføring vil den iterasjonsbasert tilnærmingen redusere og snevre inn usikkerheten iterasjon for iterasjon. For hver iterasjon samler man data, bygger erfaringer, reflekterer rundt og justerer estimatene.

Du er nettopp servert nok et argument for at smidig prosjektgjennomføring er tingen!

Som utdannet ingeniør og teknolog verdsetter jeg faglig kompetanse meget høyt. Tung faglig kompetanse er helt klart en nødvendighet og også påkrevd for å få løst mange tekniske utfordringer. Ikke bare løser man problemet og utfordringer, man har også stor sannsynlighet (men ingen garanti!) for at det er utført med kvalitet.

Observasjoner jeg gjør i daglige og som jeg har begynt å gjøre noe betraktninger rundt, er om et tungt faglig miljø er ensbetydende med et produktivt miljø? Kunne man med en litt annen sammensetning av mennesker vært minst like produktive eller kanskje til og med mer produktive?

Hva er det som gjør at sub-teamene i en avdeling fungerer så vidt forskjellig? Noen team er utadvendte og gjør mye av seg, mens andre produserer i det stille med lite kommunikasjon mellom teamdeltakerne. Faglig har alle teamene mer eller mindre samme kompetansebakgrunn og nivå. Tendensen er allikevel klar; de teamene som kommuniserer mye og som ”tar mye plass visuelt og i støy” produserer mer, treffer bedre på estimatene (faktisk er trenden at man leverer før…) og har høyere kvalitet i leveransene.

Hendelser jeg kjenner til fra bransjen, viser noe av det samme. Man kan bemanne et prosjekt og intervjue til fast ansettelse og leie inn konsulenter med det formål å få best mulig faglig kompetanse tilgjengelig, men det er ikke sikkert det allikevel er tilstrekkelig. Min erfaring tilsier at man må legge minst like mye vekt på sosiale egenskaper som de faglige. Prosjektdeltakere må utfylle hverandre ikke bare på faglige områder, men også som mennesker og typer.

Mennesker som samhandler og trives sammen jobber bedre sammen. Resultatet er bedre kvalitet og høyere leveransetakt.

Og så kan det faktisk være da, at Scrum med sine daglige ståoppmøter kan virke som et positivt virkemiddel for å folk til å samhandle og dele informasjon… Og så kommer gleden av å jobbe og levere sammen og derav kvaliteten og leveransetakten ”helt” av seg selv?

- Inge

I det siste har jeg studert en del av prinsippene og teoriene bak smidige prosjektrammeverk som Scrum. De fleste som er kurset i Scrum vet at Scrum bl.a. er basert på LEAN. LEAN har hentet mye av sin beste praksis fra prinsipper og filosifien som ble utviklet i perioden 1948-1975 i det som kanskje er verdens mest vellykkede produksjonsselskap: Toyota.

Grunnleggerne bak Toyota utviklet det som omtales for Toyota Production System (TPS) og prinsippene bak dette systemet omtales The Toyota Way. Det er i disse prinsippene jeg finner mye spennende som kan jeg kan bruke til min fordel og i min egen hverdag som rådgiver og prosjektleder.

Prinsippene finner du her: http://en.wikipedia.org/wiki/Toyota_Production_System

Av disse finner jeg følgende stikkord som helt sentrale for å få et optimalt prosjekt og leveransemiljø:

1. riktige prosesser gir rett resultat
   • fokus på kontinuerlige prosesser og flyt i produksjonen bidrar til å synliggjøre problemer (scrum: hindringer/impediments)
   • søk jevn arbeidsbelastning - koordinerte prosjektteam og organisasjonen forøvrig må være jevnt skalert for å få best mulig flyt (ingen vits om utviklerne produserer masse, om ikke testerne eller de med ansvar for utrulling ikke henger med... Eller at produkteierene ikke klarer å holde tritt med utviklingstakten. De fleste Scrum-predikantene fremhver også viktigheten av et jevnt leveransetempo)
   • bygg en kultur for å stoppe opp og rette feil umiddelbart - invester i kvalitet fra første stund! (her mener jeg det ligger mye i både fokus på funksjonell test, men også at man legger testdrevet utvikling som basis for utviklingsstrategien)
   • bruk visuell kontroll - personlig har jeg kjempetro på prosjekttavler og andre visuelle virkemidler for å visualisere fremdrift, status og for å stimulere til at hindringer og problemer blir avdekket tidlig. Derav er jeg en tilhenger av samlokalisering av prosjektressurser...
2. Øk verdien av produktet og organisasjonen ved å stimulere og utvikle ressursene og partnerne dine
   • Bygg ledere som har grunnleggende forståelse for arbeidet som utføres - hva er vel mer irriterende enn en leder som overhodet ikke skjønner hva vi driver med?
   • Bygg eksepsjonelle mennesker og team - Hør! Hør! Dette er både viktig og gøy! Alt for mange mennesker jobber i avdelinger og såkalte team uten særlig inspirasjon og motivasjon. Kanskje en leders viktigste oppgave?
   • Respekter ditt nettverket av partnere og leverandører ved å utfordre og hjelpe dem til å forbedre seg - for oss i Amende en helt naturlig ting! :)
3. Bli en kontinuerlig lærende organisasjon
   • Du må selv oppsøke og se problemstillinger som oppstår for grunnleggende å forstå situasjonen
   • Søk enighet og konsenus i besluttninger - selv om det tar tid. Implementer raskt!
   • Bli en kontinuerlig lærende organisasjon gjennom refleksjon og kontinuerlig forbedring - (Dette finner vi igjen i Scrum gjennom de retrospektive møtene på slutten av hver iterasjon)

Mange av disse punktene er "heavy stuff" og er helt klart ting som ikke kommer av seg selv. Men hvem har vel sagt at ledelse og ikke minst produksjon av programvare er lett?

Jeg dykker mer ned i materien og hører fra meg igjen - ser for meg et hav av lyspunkter og gode teknikker og prinsipper fra Toyota som vil hjelpe meg til å bli en enda bedre leder og rådgiver.

- Inge

I et intervju med Dagbladet 07.12.08 og på spørsmål om hvordan man skaper suksess, svarer roeren Olav Tufte: "Ved å søke etter utvikling". Det slår meg at der roeren Olav søker utvikling og perfeksjonerer roteknikken og presser marginer i treningsøktene, så er det nettopp dette som er essensen (eller burde være!) i alt det vi gjør ellers også - både på jobb og privat.

Siden jeg i mitt yrke jobber mye med programvareutvikling og ledelse er det naturlig å gjøre koblingen fra Olavs svar til noe meget grunnleggende, både når det gjelder generelt om det å lære og ikke minst innen smidige prosjektmetoder.

Læring - en prosess i seg selv
Hver dag gjør de fleste av oss en rekke vurderinger og beslutninger. Erfaringer fra disse utgjør etter hvert et grunnlag som vi bygger videre på - vi lærer. Og vi lærer kontinuerlig. Hele tiden.

La meg ta et eksempel på en meget enkel læringsprosess; du går bortover en korridor og i korridoren står en stol. Du observerer stolen og jo nærmere du beveger deg stolen må du etter hvert foreta et valg; du kan gå rett på stolen eller du kan vurdere å gå rundt. La oss anta at du fra før vet at en stol er hard og at dermed av erfaring vet at det å gå direkte gå på stolen vil gjøre vondt. Du beslutter å gå rundt stolen og fortsette upåvirket til hva du nå egentlig er på vei til...

Hva er det egentlig som skjer i dette tilfellet? Jo, det starter med at du samler data. Gjennom synet registreres stolen og i løpet av noen nanosekunder er plasseringen av stolen og avstanden til omkringliggende vegger/gjenstander vurdert til at det er plass til å komme passere uten å måtte hoppe over eller flytte stolen. Basert på data, vurderes muligheter og man trekker en slutning. Kanskje brukes også denne kunnskapen til neste gang du vurderer å velge denne korridoren.

Man følger altså et mønster:

1. Samle data.
2. Vurderer og analyserer data.
3. Trekker en konklusjon og gjør tiltak.

Man bruker konklusjonen og situasjonen neste gang den oppstår. Man har lært og man har en evig løkke av utvikling.

Læring i smidige prosjekter - retrospektiver
Så hvordan skaper man suksess i smidige prosjekter? Ellers om Olav ville ha sagt; hvordan søker man utvikling? Hvordan forbedre opp mot det perfekte? 

Svaret ligger i en av de kanskje viktiste prinsippene i rammeverk som Scrum   - "inspect and adapt". (For de som kjenner rammeverket MSF, så løses dette gjennom "no-blame milestone review"). Prosjektrammeverkene oppfordrer oss altså til å inspisere og samle data, vurdere disse og tilpasse oss slik at vi har utviklet oss til neste gang eller til neste iterasjon. Er ikke det akkurat samme situasjon som når vi møter på stoler i korridorer... :)

I scrum er det de retrospektive møtene på slutten av en iterasjon som gjør at vi kan ta med oss kunnskap om det vi har gjort videre til neste iterasjon. Man søker altså en kontinuerlig utvikling og forbedring. Iterasjon for iterasjon, release for release,  prosjekt for prosjekt...

Konklusjon
Det er mange veier til suksess. En av disse er fokus på og evig søken etter utvikling. Utviklingen kommer gjennom kontinuerlig læring og evaluering av hva man nettopp har gjort og dermed bygge videre på dette.

Akkurat som Olav har brukt mange år på å bygge styrke, kondisjon og teknikk, tar det tid for et prosjekt, team eller selskap å bli en suksess. Så lenge man er trofast mot prinsippene for å søke utvikling, er man iallefall på god vei til suksess; det være seg OL-medalje, å levere på tid, levere på budsjett eller med maksimal kvalitet.

Lykke til!

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.