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