Category: Projects

Mycket med tema anställda och anställningar just nu.

Detta är tänkt som en kort rekomendaton av en bok: Anställda från BL information (Björn Lundén)

Då jag behövda sätta mig in i vad som gäller för lagar och regler lånade jag denna bok på biblioteket, och blev imponerad. Boken berättar bra och pedagogiskt vilka regler som gäller. Men framförallt är den inte långtråkig, utan går till och med snabbt att läsa. Trots att den är på över 400 sidor. Den lyckas även verka heltäckande, med allt från vilka skyldigheter man har när man rekryterar till hur man ersätter anställda för resetraktamenten.

Kortfattat har boken gett mig två saker.

Insyn i vilka rättigheter jag som anställd har när jag jobbar och även nu som arbetsgivare.

Gjort klart för mig att fackföreningar säkert är ett gott syfte, men inte är det bästa för alla företag.

Detta är egentligen en bok alla som jobbar också borde läsa. Man lär sig vad man får och inte får göra, och framförallt vad som är rimligt. Och småsaker, som sjukdom på semestern inte räknas som semesterdagar (om du anmäler det) eller vilka rättigheter till lön man har om man någongång jobbar som jour.

En vecka kvar nu till första löneutbetalningen. Hoppas vi det går bra.

Lärde mig igår att peacocking är när man förklarar något med beskrivande adjektiv, istället för med fakta. Vilket egentligen var det jag gjorde med boken Critical Chain. Så jag tänkte istället försöka berätta lite om vad boken egentligen tog upp.

Det börjar med en genomgång av projekt. Projekt består av många mindre arbetsmoment ihoplänkade till ett mål, projektmålet. Dessa arbetsmoment kan variera mycket. De kan ta lång tid eller kort tid. Kräva att andra arbetsmoment är utförda först, eller vara oberoende tidigare steg. De kan utföras av andra grupper/enheter/personer eller av samma hela tiden.

Då var det avklarat. Det intressanta börjar när man tittar på tid, och faktorer som påverkar tider. För projekt brukar dra över på tiden, detta har nog alla upplevt.

Det finns enligt boken 3 säkerhetsfunktioner som ska se till att tiden räcker.
1) När man uppskatar varje arbetsmoment gör man det med god tidsmarginal. Man räknar i boken med att uppskattningar görs så att chansen att klara av arbetsmomentet i den angivna tiden är 90%.
2) När många arbetsmoment räknas ihop av projektledningen lägger dessa ofta till ännu en tidsmarginal. För att de har lärt sig att allt tar mer tid.
3) Ledningen, som ska godkänna tidsplanen, kräver ofta att den ska förkortas, för att det tar för lång tid. En sådanförkortning drabbar ofta varje steg, och är jämt fördelat på hela projektet. Därför har varje steg lärt sig att man alltid ökar sin tidsplan med ca 20% extra säkerhetstid, så att dessa kan tas bort när tid ska strykas.

Detta är väldigt intressanta observationer. Speciellt intressant är 1). Hur mycket extratid uppskattar varje arbetsmoment att de behöver? Boken argumenterar att i ett vanligt fall, skulle arbetstidsuppskattningen se ut så här.

90% säkerhet känns helt ok, kanske är den så låg som 80% ibland. I ovanstående exempel skulle 90% säkerhet gå en tid på strax under två gånger tiden med 50% säkerhet.

Men tyvärr kan man inte använda vanliga gaussiska fördelningar på arbetsmoment. Dessa ser enligt honom snarare ut så här.

Anledningen är att arbetsmoment inte kan gå ner mot 0 i tid. Och samtidigt är risken inte försumbar att ett oförutsedd problem dyker upp, och då skjuter tiden lätt iväg. Om man jämför tidsskilnaden mellan 50% och 90% här, är tiden mer än dubbel så stort, snare 3 gånger så stort. Man kan argumentera här exakt hur mycket det är och den är garanterat olika för varje unik arbetsmoment. Men den viktiga observationen är att man har väldig hög säkerhetsmarginal, jämfört med vad medelvärdet på projekttiden är.

Slutsatsen är att ett projekt innehåller i grund och botten väldigt mycket säkerhetstid. Även en låg uppskattning skulle säga att projekttiden är minst till hälften säkerhetstid. Detta borde betyda att många projekt borde bli klara långt innan sin deadline. Men sker detta i verkligheten?
Det gör det så klart inte.

Anledningen är att det också finns 3 funktioner som äter upp den här säkerhetstiden.
1) The students syndrome – att man inte börjar med något förrän i sista stund, även om man har god tid på sig
2) Multitasking, som gör att varje enskild arbetsmoment blir klar senare än om man suttit med det enskilt.
3) Arbetsled, att vissa steg inte kan börja innan ett tidigare är klart. Är det tidigare steget försenad börjar nästa steg försenad.

Detta är intressanta observationer, som han sedan använder för att visa det som The Goal sade för produktion: säkerhetstider på moment som inte är flaskhalsen är onödig, till och med destruktiva. I ett projekt är flaskhalsen nästan alltid “the critical path”, dvs det led av arbetsmoment som tar längst tid att klara av. Alla andra tar ju mindre tid, och är därför inte avgörande för när hela projektet är klart.

Boken går sedan in på praktiskt tillämpning. Hur ska man sätta uppskattningen av arbetstid för olika moment, och var ska man sätta in buffertzoner för att minska risken för förseningar.
Den går också in på hur man belönar projekt på fel sätt. Mycket av detta man ser kommer ifrån att man inte uppmuntrar att man blir klar tidigare än planerat. Det existerar i många fall inte alls.
Där kommer bl.a. det där med 50% chans att hinna klart in. En 50% chans att hinna klart inom en given tid är en acceptabel uppgift, enligt Goldratt. Detta förutsatt att de som jobbar med uppgiften inte blir bestrafade för att bli klara för tidigt.
Han menar att man istället ska mäta efter tid kvar tills man är klar. Och varje dag göra en ny uppskattning (eller vecka, beroende på totala tiden). Denna uppskattning flukturerar starkt, men är mycket mer användbar. Dock bara på de moment som ingår i flaskhalsledet. De andra spelar ingen roll, så länge inte dessa blir till flaskhalsar. Goldratt förklarar det lite bättre förklarad bara, än vad jag lyckas på mina 10 rader.

Som jag sade i mitt förra inlägg, mycket intressant och ögonöppnande. Självklarheter, så klart. Men genomtänkta lösningar.

När man nu kommer till kritan dock, om denna nyvunna inblick hjälper mig i mitt projekt, måste jag säga att jag inte vet. I dagsläget har jag inte ens ett flödesschema på projektet, och har ingen aning om vad som är mitt flaskhalsled. Ska jag lägga tid på att ta fram detta? Kommer jag se resultat av en sådan sak? Mitt projekt är ju väldigt blandat, med många okändheter och många externa arbetsmoment. Kan jag uppskatta tiderna? 50% sannolikhet…?

Denna vecka försöker jag ha en ‘filosofi vecka’. Denna går ut på att reflektera över projekt Danmark och se om jag kan komma på några nya infallsvinklar. (som några kanske har märkt namnger jag saker efter känslor och inte rationalitet ibland). Borde väl heta ‘brainstorm vecka’ egentligen.

Hur som helst, för att finna dessa potentiellt bra lösningar har jag läst “Critical Chain”, från vår kära Eliyahu M. Goldratt. Hans tredje bok. Jag vill här egentligen bara säga att detta är en mycket bra bok. Har nu läst fyra av hans böcker (tror inte det finns många fler), och detta är nog den bästa. Precis som “The Goal” fokuserar den på TOC, men tar också in “the evaporating cloud” från andra boken. Men framförallt fokuserar denna bok inte på produktion, utan på projekt. Vad är en constraint i ett projekt, och hur optimerar man denna. Mycket intressant.

Förutom det har boken även den bästa handlingen av alla hittills. Bra karaktärer, och inte så ‘iscensatta’ handlinger som det ibland har varit i dem andra. Mycket roligt så klart.

Pratade för ett tag sen med Dan om hur pass bra Goldratt egentligen är. Man får väldigt mycket inspiration från honom, och han framställer sina teorier som väldigt allsmäktiga. Men ändå så verkar han inte vara så känd. Och hur svårt är det att tillämpa hans teorier i praktiken, egentligen? Lite motsägelsefult är det hela.
Men min kännedom om produktion är mer eller mindre noll. Projektledning däremot har jag kommit i kontakt med, men ändå inte. Har aldrig arbetat med en stor, erfaren, projektgrupp. Men när man läser på lite verkar han i varje fall inte vara en bluff, som en viss annan person. Tiden får kanske avgöra hur bra han egentligen är.