Skip to content

Latest commit

 

History

History
58 lines (29 loc) · 10.6 KB

File metadata and controls

58 lines (29 loc) · 10.6 KB

Skillnad 1 - Linjära projekt

Skillnad 1 - Linjära projekt

De processer och arbetsflöden som vi fått från den industriella revolutionen är så djupt rotade i oss att vi ibland ser dem som helt självklara, helt utan alternativ. (Men även utan motiv!) Och ibland ser vi dem inte ens, de är helt integrerade i våra organisationer och vår mentala bild av hur arbete ska gå till. Oavsett vad vi ska producera.

Säger det inte sig självt att det är mycket mer effektivt att jobba som ett löpande band jämfört med innan då en eller två personer gjorde ten stol från scratch tills den var klar?

Givet vad som skulle produceras och den teknologi som fanns tillgänglig då, så gav det absolut mycket högre produktivitet. Frågan är dock om det blev roligare att jobba så? (Har vi inte haft en hel politisk rörelse och flera organisationsteorier som tar sin ansats i hur arbetstagaren ska få mer inflytande och att det är en win-win?) Från idén bakom det löpande bandet kommer också mycket av företagens klassiska struktur: Vilka avdelningar man är indelade i och hur de förhåller sig till varandra. Enkelt beskrivet lämnar en avdelning över till nästa när den är klar med sin arbetsuppgift.

Arbetet sker som en stafett.

I takt med att organisationer och vad de producerade blev mer komplext och började innehålla en allt större andel tjänster, utvecklades det mentala löpande bandet och ett gammalt fint ord blev modernt igen -- vi började arbeta i projekt. En arbetsform som blev särskilt vanlig i verksamheter som inte sysslade med produktion i vanlig bemärkelse -- som inte gjorde fysiska produkter -- utan producerade bara tjänster eller andra typer av nyttor, till exempel myndigheter och Public Service-verksamheter. Vi känner alla igen begreppet förändringsprojekt.

Som en effekt av den ekonomiska krisen i början av 1990-talet sköljde en effektiviseringsvåg över näringslivet och snart skulle en person utföra samma volym av arbete som tre-fyra hade gjort tidigare. För att göra detta möjligt eller -- enligt de mer cyniska bedömarna -- för att dölja att detta var målet, så blev det populärt att gå över i projektorganisationer. (Eller är detta egentligen från sjuttiotalet?)

Och även om projekten ibland kunde lösa upp avdelningsgränser något genom att ha medlemmar från fler än en avdelning, fortsatte de att vara linjära inom projektet. Ett projekt har allt som oftast en tidsplan och diverse deadlines längs med den tidsplanen. Och sen, när projektet är genomfört, då är man klar!

En mycket lustig bieffekt av de senaste femtio(?) åren av projekt är att den arbetsformen nu blivit mer gammeldags än flera av dem som vi hittar inom traditionell produktion. Hur kan det komma sig?

Jo, det beror på att det vanligaste sättet att arbeta i projekt inte bara är linjärt, utan också är sej selv nock, som våra norska grannar skulle säga. Det är uppdelat i olika faser, där övergången från en till en annan är inplanerad i tidsplanen, och där rörelsepilen alltid går åt ett håll: “framåt”. (Det är som klassisk kausalitetsbaserad fysik jämfört med kvantfysiken. Ett knäckt ägg går inte att få ihop igen, men alla fotoner tar alla möjliga vägar genom en växt för att fotosyntesen ska fungera.)

I den första fasen målar projektets medlemmar upp vad det är de ska leverera. Vi kan kalla det för idéfasen och normalt förs resonemang kring ett antal olika idéer fram och tillbaka tills projektgruppen genom konsensus eller ett beslut från en projektledare eller chef bestämmer vad som är en “bra idé”. Att presentera den idén är en vanlig första deadline, en leverans som avslutar den första fasen och som är en beslutspunkt för de följande. Och den andra fasen är den första av flera i realiserandet av den idé man beslutat förverkliga.

Ni vet hur det går till. Man brukar kalla dessa projekt monolitiska eftersom de som sagt är sig själva nog och eftersom det förekommer väldigt lite extern påverkan på projektet utom, ibland, när chefer är med vi de olika beslutspunkterna. Den enda, stora externa påverkan sker precis i början när projektet definieras. Antingen genom att något tillverkats klart hos en annan avdelning, som när en förläggare är klar med en bok och lämnar över den till marknadsavdelningen. Eller genom att någon beslutat om en förändring eller leverans av något. Ibland också genom att man genomför en förstudie och gör research och får input från olika remissinstanser för att definiera projektet.

Och när projektet väl definierats så ändras det väldigt sällan.

Det här sättet att investera mycket tid och resurser “inom” projektet är vad som får vissa att kalla projektbaserade företag för dinosaurier. Man brukar också säga att projekt är top heavy eftersom det går åt mycket tid och resurser till planering, research och idéarbete i början. I de flesta fall är projekt också klara innan de får någon feedback från de som är målgruppen för projektet. I bästa fall nöjer man sig med att skaffa in “data” om dem i början, under research-fasen. Ofta följer det som en logisk följd -- eller så har vi trott länge -- att det är först när projektet levererar vad det nu är som ska levereras som människor utanför projektet kan ge sin respons. Vare sig de är kunder, medborgare eller patienter. Och det är ett annat exempel på varför projektet är monolitiskt: Hela projektet är klart innan det levereras.

Traditionellt har denna feedback också haft väldigt låg upplösning. Jämfört med de resurser som spenderats på och under projektet är det ofta väldigt lite som läggs på att ta reda på vad mottagarna tyckte. Att mäta resultaten. För det mesta är målgruppen just också sedda som mottagare av projektet. Inte deltagare i det. Inte bara sedda som det, förresten. Om de inte är inblandade under gång är de inget annat än passiva mottagare.

Så förutom att alla projektets resurser normalt redan gått åt när man får feedback, så är det också försent. I “projekttid” tog det en väldigt lång stund innan man fick feedback -- ända tills man var klar!

De nya arbetssätten ställer allt detta på huvudet.

För det första jobbar man helt enkelt inte i projekt, utan i värdeflöden som istället för en lång tidsplan består av korta loopar. Ett värdeflöde är helt enkelt ett arbetsflöde som triggats av ett kundbehov eller kundbeteende och som levererar vad som tillfredsställer det behovet. Det leder till att arbetet inte är linjärt utan parallellt. En digital tjänst levererar på flera olika värdeflöden samtidigt.

För det andra så är man inte heller “top heavy”. Istället gör de nya arbetsflödena målgruppen eller kunderna till deltagare och tar in feedback på en gång. I exemplet med förläggaren ovan, skulle vi kunna säga att när första kapitlet är klart får några läsa det och de som ska marknadsföra boken är med i processen och får höra den feedback som kommer in. För oss som är så vana vid industrialismens processer, där produkter måste vara “klara” innan de “levereras” låter det kanske konstigt. Men det var så Andy Wiers bestseller The Martian skrevs. Kapitel för kapitel med feedback från läsarna under vägen. Troligtvis förvånar det då heller ingen att han inte hade ett förlag än. Det är inte det traditionella, industriella sättet att skriva en bok. Det var han själv som ville jobba på det nya sättet.

[Faktaruta/illustration: Skärmdump från GitBook, slash nav- och ekerdiagram för hur människor lämnat in feedback.]

Bildtext: Nu undrar du förstås hur det gått till när den här boken skrevs. Och författaren har använt molnverktyg som Trello och GitBook för att göra det möjligt för “beta-testare” att komma med feedback på tidiga versioner. Mer om GitHub och GitBook i kapitel X.

Så om vi lägger ihop det klassiska projektets faser till en lång tidslinje för hela projekt så kan vi väldigt enkelt se skillnaden mot de nya arbetssätten. Redan under projekts första vecka -- eller första två veckor beroende på hur du vill jobba -- har det nya arbetsflödet gjort något, producerat något och fått feedback på det. Flödet har genomfört en loop med problemdefinition, hypotes, skiss och leverans av en “prototyp” som testar hypotesen. Mer om beståndsdelarna i denna loop senare.

Och feedbacken som teamet får in i slutet av loopen blir input, kunskaper som arbetet i nästa loop baseras på.

Anledningen till att detta är möjligt är att till skillnad från i projektet så är arbetet inte monolitiskt. Det som förut var projektet är istället sönderbrutet i delar som är tillräckligt små för att kunna hanteras under en loop. Precis som ett kapitel i Andy Wiers bok, jämfört med hela boken eller till och med en del av boken.

Istället för projektets deadlines som också är beslutspunkter, där beställare, chefer eller en styrgrupp ska ta ställning till hur man går vidare, så har det nya arbetsflödet leveranser som är läropunkter. Som dessutom sker oftare än projektets beslutspunkter. Och om vi nu påminner oss om att det övergripande syftet med det vi diskuterar är att öka farten på den digitala utveckling i och av organisationen och öka värdet på vad den levererar, då kan det vara mycket intressant att titta lite närmare på den här skillnaden.

I den gamla världen har vi en beställare, en chef eller en styrgrupp. Dessa är exempel på ett fåtal, interna individer med sin uppsättning av erfarenheter och kompetens. I den nya världen har vi feedback direkt från målgruppen. Kunder, medarbetare, medborgare eller vilka de än är. De som ska använda slutprodukten i fråga. Vilka av dessa två olika “beslutsfattare” kommer att ge bäst input i förhållande till att det som ska levereras ska skapa värde för kunderna, medarbetarna eller medborgarna?

Nu ska vi inte vara onödigt elaka mot de gamla projektledarna och cheferna. Det är först med de nya, digitala verktygen vi kan få denna feedback från användarna av våra tjänster och produkter så snabbt och kostnadseffektivt. Det är det man menar när man säger att man jobbar datadrivet. Faktum är att vi kan få dessa kunskaper i realtid. Alltså måste vi också organisera oss så vi drar nytta av den nya förmågan.

Och här ser vi alltså ett tydligt exempel på hur de nya arbetsprocesserna skapar högre fart och högre värde. (Något som förut var motsättningar.) Genom att dela upp arbetet i moduler levererar de nya arbetsflödena mycket oftare än projekten gjorde och tar vid varje leverans in nya kunskaper om vilka lösningar som är bra eller dåliga ur kundens ögon.