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:

17. mai	Norges Nasjonaldag. Ikke noe grunn til å estimere siden vi vet nøyaktig hva svaret er. Behovet for å synliggjøre usikkerhet er ikke til stede.
Hvor høyt er norges høyeste fjell?	Noen vil huske dette eksakt fra barnelærdommen, men de fleste vil angi et område som de tror vil treffe. Et rimelig resonnement vil være: høyere enn 2000 meter, men ikke høyere enn 3000 meter. Vi er ikke sikre, så vi tar høyde for usikkerhet ved å svare 2000 – 3000 meter. (Galdhøpiggen er 2469 meter høy).
Hvor mye veier en pyramide?	Det blir helt urimelig å begynne anslå noe som helst. Man hva skulle nedre og øvre grense være dersom du skulle komme med et anslag som ga 95 % sikkerhet? Mellom 0 og uendelig tonn? Skulle man kommet med noe som ga en viss trygghet i estimatet (redusert usikkerhet), ville det være å jobbe frem en modell som beregnet massens egenvekt, høyde, bredde og volum – med andre ord man må utføre et stykke arbeide for å redusere usikkerheten.
11232,5	Et så nøyaktig tall formilder noe konkret og bør være dokumentert. Sum fra en timeliste eller sluttresultatet for et delprosjekt? Må aldri fremkomme i et estimat!!
11000	Se på dette tallet og sammenlign det med det på linjen over. De to tallene er ganske størrelses messig like, men gir inntrykk av noe helt forskjellig. Det øverste noe konkret og det med 0 gir et mer inntrykk av et estimat. Avrundinger og bruk av 0’ere bidrar til å formidle usikkerhet.
10000 – 13000	Ved å angi et område eller serie og i kombinasjon med 0ere har man klart formidlet usikkerhet.

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