Derfor holder budgetterne ikke, når projekter skal realiseres

"Mennesket ser for lyst på fremtiden – bevidst og ubevist - og derfor holder budgetterne ikke, når store byggeprojekter skal realiseres." Oprindelig artikel fra Ingeniøren af Bjørn Kock Sørensen

Jeg faldt over dette citat i denne artikel og selv om den går på byggeprojekter, og uden at have nærmere på Bent Flyvbjergs arbejde, eller på Daniel Kahnemans for den sags skyld, mener stadig jeg det holder på de projekter jeg har været tæt på.

Skal man budgettere ud fra hvad man ud fra hvad man ved, det vil sige ikke se spøgelser?
Skal man være pessimistisk?
Skal man gøre det nedefra-op eller oppefra-ned?
Eller hvad med Planning Game?

---

Kender du Bent Flyvbjerg og Daniel Kahnemans arbejde? Er du enig med deres perspektiv?

Hvordan estimere i arbejdet ved jer?

Årsags/Effekt diagram

Et af de værktøjer jeg, engang imellem, finder frem fra min værktøjskasse er et "årsags-effektdiagram".

Se en beskrivelse her: http://en.wikipedia.org/wiki/Ishikawa_diagram

Det er et super værktøj til at brainstorme over et problem på - forleden brugte jeg og en anden chef kollega på dba.dk værktøjet til at identificere en række årsager til store udfordringer vi har lige nu.

Den store udfordring med værktøjet er at det giver lidt et sortsyn på situationen - du får en rigtig god liste over årsager til problemer, og viser typisk hvor komplekt situationen er.

Har du nogle erfaringer med dette eller andre værktøjer?

------

Jeg har ikke selv brugt det, men her har du et online tool:

http://www.pptmagic.com/downloads/ProjectMgm/Fishbone.swf

Hvornår har dit team fejlet sidst? Og hvad fik i lært?

Hvis du ikke fejler betyder det at du ikke laver fejl, hvis du ikke laver fejl presser du ikke dig selv.

Når du presser dig selv laver du fejl, for at forbedre dig selv, skal du presse dig selv endnu mere, og du risikerer at fejle.

Jo mere du presser dig selv, jo hurtigere bliver du bedre, og jo hurtigere kommer du i mål.

"Fail often to succeed sooner"

Hvad skal man lave først?

Når man skal bestemme hvilke opgaver der skal laves først, er der to strategier som begge på overfladen virker meget fornuftige.

1) "Gå efter quick-wins"
Få de hurtige succeser, lav så meget der kan laves så hurtigt som muligt, og gem det svære til senere.

Ulempe: Du skubber, de tunge opgaver til senere, og det kan være svært at estimere dem
Fordel: Du vinder viden om projektet mens du arbejde med dine "quick wins", kunderne bliver klogere
Fordel: Dit team bliver motiveret.

2) "De største risici først"
Er der noget der har en risiko for projektet? Få det ud af verden med det samme.

Ulempe: Der kan gå lang tid før ens team præsenterer resultater
Fordel: Risikominimering naturligvis

Alistair Cockburn omtaler tilgangene Worst Thing First og Easiest Thing First, Hardest Thing Second. Hvor første tilgang kan sammenlignes med "De største risici først", når det kommer til tekniske risici, så kan anden tilgang ikke helt sammenlignes med "Quick wins", fordi ideen er at man laver én utrolig nem ting først, og dernæst det svære. På den måde motiveres projektteamet ved en tidlig "sejr", og denne faktor bør nærmest indgå i en hver projektleders repetoir for risikominimering: Har du et motiveret team, er der næsten ikke grænser for, hvad der kan laves til tiden (næsten da..).