Du har förmodligen hört den stora nyheten: multitasking är en myt. Ändå är praktiskt taget alla skyldiga till att växla mellan flera projekt samtidigt - samtidigt som de svarar på e-postmeddelanden, samtal i förbifarten, telefonsamtal med mera. När vi pressas att leverera snabbare överväldigar vi ofta oss själva genom att försöka ta på oss fler uppgifter, vilket oavsiktligt försvagar vårt fokus och gör oss långsammare - mycket långsammare.
På Fortezza Consulting hjälper jag team att uppnå dramatiska förbättringar av prestanda - ibland med 3x eller mer. Den viktigaste byggstenen är att utföra en enda uppgift: Att fokusera på att leverera kvalitetsarbete, en bit i taget. Effekten av single-tasking är dramatisk på individnivå och omvälvande på organisationsnivå.
I komplexa organisationer med högt tempo är det omöjligt att genomföra enstaka uppgifter utan ett disciplinerat tillvägagångssätt. Det är här som WIP-målen (work-in-process) kommer in i bilden. Fortsätt läsa och titta på inspelningen av detta webbseminarium för att få veta varför WIP-mål fungerar enligt Lean och Kanban och hur man tillämpar dem på företagsnivå.
Lean, Kanban och WIP
En viktig princip i Lean och Kanban är att visualisera det faktiska arbetsflödet. Genom att visualisera sitt arbete kan grupperna kontinuerligt identifiera möjligheter till förbättringar. Kanban-tavlor hjälper teamet att visualisera prioritet, status, tilldelade teammedlemmar, förfallodatum med mera för varje arbetsuppgift. De kan också se vilka problem som blockerar arbetsflödet - till exempel flaskhalsar och blockerare - och kan arbeta för att förbättra processen för att uppnå ett kontinuerligt flöde. Det är genom denna process av kontinuerlig förbättring som grupperna kan arbeta för att nå sina prestationsmål.
En annan viktig del av Kanban är att använda ett pull-system - vilket innebär att grupperna drar in arbete i systemet i takt med att de har kapacitet (i stället för att få arbete "tryckt" på sig utan hänsyn till arbetsbelastningen). För att ha ett pull-system måste teamet ha en prioriterad backlog och en tydlig process för prioritering. På så sätt kan alla medlemmar i teamet lägga in prioriterat arbete i systemet i takt med att de har kapacitet.
Det gör det också möjligt för teamet att införa WIP-gränser - eller helst WIP-mål. Genom att begränsa WIP kan grupperna fokusera på att förbättra kvaliteten och hastigheten på arbetet. WIP-målen öppnar en ny nivå av prestanda genom kraften i enstaka uppgifter och främjar en kultur av experiment och samarbete som kan vara en katalysator för att nå ännu högre prestationsmål.
Vad du får lära dig
I det här webbseminariet introducerar jag begreppet WIP-mål och deras tillämpning i företagsskala, och tar upp viktiga frågor som t.ex:
- Hur kan vi känna igen när det är dags att optimera WIP?
- Hur vet vi vad det rätta WIP-målet egentligen är?
- Hur kan vi använda WIP-mål för att främja autonomi och självförvaltning i teamet?
- Hur hjälper vi både ledare och kunskapsarbetare att göra den nödvändiga förändringen i tankesättet?
- Hur skalar vi upp tillämpningen av WIP-mål i hela företaget?
Du lär dig hur du kan främja experimenterande och samarbete och nå oöverträffade resultatnivåer med ditt team.
Titta på inspelningen
Bläddra igenom min bildspelsplan här.
10 Vanliga frågor om WIP-mål
F: För ett team med 20 parade programmerare, menar du att de bara ska välja ett Team WIP Target på 10?
S: Ja! För dem som kanske inte känner till vad parprogrammering innebär det helt enkelt att två programutvecklare (programmerare) samarbetar med varandra för varje uppgift. Det är alltså logiskt att ett team med 20 skulle ha ett Team WIP-mål på 10.
Men om en eller två medlemmar i teamet med 10 är erfarna experter som bättre kan hjälpa till att förbättra teamets flöde genom att "flyta" till vilket par programmerare som helst som kan behöva hjälp med att påskynda saker och ting, kan teamet ha nytta av att utforska ett team WIP-mål på 9, eller kanske till och med 8.
F: Med så många team som alla har så mycket självständighet, hur skulle du kunna skala detta över en stor organisation med någon nivå av konsekvens?
S: Den aspekt som kräver en icke förhandlingsbar konsekvens är "Hur kan vi...?"-kulturen, som bygger på disciplinen för en enda uppgift - och allt som kan göras för att främja och förstärka den kulturen.
Om varje enskilt team kommer fram till radikalt olika Team WIP-mål - men alla är baserade på en stark disciplin för enstaka uppgifter - har ni troligen just uppnått något verkligt fantastiskt.
Nästa steg för projektcentrerade miljöer är att lyfta konceptet Team WIP Targets till projektportföljnivå (WIP på projektnivå). Att få både WIP på uppgiftsnivå och WIP på projektnivå att överensstämma med kapaciteten är det bästa receptet jag känner till för att få en dramatisk ökning av genomströmningen i projektets slutförande.
F: Hur kan jag få mina team att köpa in sig?
S: Jag gillar att börja med att bjuda in folk att spela det spel med en enda uppgift som beskrivs på bilden nedan - det tar bara ungefär 10 minuter att spela och kanske 10-15 minuter att diskutera erfarenheten och lärdomarna, så totalt tar det mindre än 30 minuter.
Vanligtvis är folk ganska förvånade över skillnaden i både hastighet och tillförlitlighet. Berätta sedan för dem om min berättelse om Rubiks kubpussel och fråga dem om de håller med om att hastighetsskillnaden troligen är ännu större när man utför komplexa kunskapsuppgifter. Fråga sedan: "Tänk om vi bara skulle kunna nå halvvägs till en idealisk miljö för fokusering på en enda uppgift?" och "Tänk om vi bara skulle kunna göra detta för våra mest erfarna, sakkunniga, "flaskhalsresurser" som arbetar med de mest komplexa uppgifterna?"
Var beredd på en blandning av reaktioner - från mycket fascinerad till mycket skeptisk - det handlar inte nödvändigtvis om att övertyga någon om något under det första samtalet, utan bara om att få igång samtalet. Be sedan om att få fortsätta samtalet, kanske genom att lägga till spelet på agendan för ett kommande teammöte eller fråga om någon har sett den senaste studien om single-tasking. Det viktiga här är att inte se det som en "buy-in"-process där du "säljer" eller trycker på något, utan som en genuin start på ett samtal av typen "Hur kan vi...?". Du kan mycket väl få intressanta och kreativa förslag som inte har något att göra med single-tasking, men som ändå kan vara väl värda att prova.
F: Hur kan vi motivera människor att delta i fler tvärfunktionella projekt och team? (dvs. internförsäljning som deltar i materialhanteringsprojekt, produktionsingenjörer som deltar i kvalitetsprojekt, kvalitet som deltar i försäljningsprojekt osv.)
S: Jag gillar att placera hela det tvärfunktionella teamet på en enda, enkel ToDo/Doing/Done-tavla när det är möjligt, och sedan använda Card Types för att spegla hela spektrumet av färdigheter som krävs. Även om du befinner dig i en mycket segmenterad, fasindelad miljö kan det vara en ögonöppnare för människor i de olika funktionerna att faktiskt se det arbete som alla har framför sig. Och med Planview AgilePlace är det enkelt att filtrera efter korttyp när du bara behöver fokusera på teamets funktion. Det är också lätt att analysera var de största flaskhalsarna finns i slutprocessen.
Om det inte är möjligt att ha en sådan enda tvärfunktionell styrelse är det bra att Planview AgilePlace erbjuder Card Connections för att visa kopplingen mellan korten - oavsett om de finns på samma styrelse eller på många olika styrelser. Det kan ta lite extra tid att få folk att göra sådana kopplingar explicita, men när några personer börjar göra det blir det lite smittsamt.
Ytterligare en mycket viktig punkt - Planview AgilePlaces utgåvor Advanced och Enterprise erbjuder också bra analyser för rapportering mellan olika styrelser. Så för de personer som har stöd för flera styrelser kan vi köra rapporter om enstaka uppgifter för att se hur många uppgifter de har att hantera samtidigt och sedan fråga "Hur kan vi hjälpa till att få det här antalet närmare en åt gången?". Utan den här rapporteringsfunktionen skulle du behöva kontrollera varje användares uppgifter på varje tilldelat forum.
F: Den första frågan som många ställer till mig är "Vad ska vår WIP-gräns vara?". Vad är ett bra råd utöver "så lågt att det känns lite smärtsamt".
S: Jag uppmuntrar dig att börja med tanken att det är önskvärt att sträva efter en miljö som fokuserar på en enda uppgift - och om folk inte håller med om att det kan vara så, se mitt svar på den tredje frågan (om att få ett godkännande från dina team).
När folk väl börjar inse att det verkligen kan vara en viktig faktor för både snabbhet och tillförlitlighet är allt du behöver göra att se till att WIP-målet inte är högre än antalet anställda. När teamet kommer allt närmare ett beteende med en enda uppgift kan du utmana teamet att experimentera med sina egna WIP-mål, som alltid bör vara lägre än antalet anställda.
Nyckeln här är att se till att alla vet att hur långt ifrån målet som teamet än befinner sig idag, med en hög WIP-nivå, så är det okej så länge som tavlan speglar verkligheten och så länge som vi verkligen utmanar oss själva genom att fråga oss "Hur skulle vi kunna jobba med WIP-nivåerna för att närma oss vårt mål för enstaka uppgifter?".
Motstå frestelsen som ledare att säga "Hej, hur kommer det sig att du har 5 uppgifter öppna - jag sa ju att vi måste göra enstaka uppgifter!" Om du gör detta kommer du plötsligt att se en tavla med artificiell harmoni: Styrelsen kommer på magisk väg att visa perfekt disciplin för en enda uppgift över en natt, även om det förmodligen inte alls återspeglar verkligheten... om detta händer har du tagit ett stort steg bakåt och måste kanske börja om från början.
F: Vi har stora produktflöden genom vårt system. Vi har infört Lean, men vi kämpar med bearbetning av enstaka delar.
Svar: Om jag förstår problemet rätt är det att höga volymer ständigt pressar WIP-nivåerna långt över kapaciteten och att "kapacitet" i detta sammanhang bäst uppnås genom bearbetning av enstaka delar, i enlighet med Leans begrepp om flödet av enstaka delar.
Om sådan bearbetning av enstaka delar utförs mestadels av människor i det här exemplet vet vi att vårt WIP-mål bör återspegla beteende med enstaka uppgifter, och mitt råd om att låta teamet experimentera med olika WIP-mål håller alltså. Om sådan bearbetning av enstaka delar huvudsakligen är automatiserad eller maskinellt utförd är det viktigt att förstå om bearbetning av enstaka delar verkligen är det som ger maximal genomströmning. För en enkelspårig motorväg är det till exempel vanligtvis optimalt med en bil i taget, men för en motorväg med 12 körfält har vi kapacitet att hantera 12 bilar parallellt.
F: Kan detta även gälla utvecklingen av fysiska produkter?
Svar: Så länge det är en miljö som är inriktad på människor eller kunskapsarbete (i motsats till en miljö som är inriktad på maskiner eller huvudsakligen automatiserad) fungerar detta lika effektivt med fysiska produkter som med programvara eller andra "osynliga" slutprodukter. Faktum är att det förmodligen fungerar bättre för fysiska produkter, eftersom det ofta är lättare att se var flaskhalsen finns när det gäller fysiska produkter - det är bara att titta på i vilket bearbetningssteg som de fysiska arbetsprodukterna (dvs. "inventarier") samlas mest, och det är vanligtvis där flaskhalsen finns.
F: Kräver beräkningar av WIP-gränserna cykeltid? Och hur mycket data behöver du?
S: Tekniskt sett, ja, men vissa organisationer överkomplicerar detta. För att hålla det enkelt gillar jag att använda kumulativa flödesdiagram som det som visas på denna bild:
Den visar cykeltider - det är bara den horisontella dimensionen eller X-axeln som Planview AgilePlace beräknar åt dig. Det finns andra Planview AgilePlace-rapporter som också tar upp cykeltiderna mer explicit, så så länge som styrelsen återspeglar verkligheten, fångas cykeltiderna upp på ett bra sätt. Nyckeln här är att CFD:s lutning bör bli alltmer brant, vilket bara kan ske om cykeltiderna minskar (förutsatt att den totala kapaciteten förblir stabil).
Jag har sett många exempel på team som strävar efter att minska cykeltiden med X %, och kanske till och med hävdar att de har lyckats med en viss minskning av målet, men det totala flödet ser ungefär likadant ut - detta är en stark indikator på att det "lokala optimala" målet kan ha uppnåtts endast på bekostnad av det totala eller "globala" flödet.
F: Hur hanterar vi WIP och hur skalar vi det?
Svar: Förhoppningsvis har jag täckt "skalfrågan" tillräckligt bra i bildspelet nedan, men om inte, kommer här en snabb sammanfattning.
För det första, sprid via "kopiera/klistra in" i flera team, med ledare på ledningsnivå som förstärker "Hur kan vi...?"-kulturen varje gång de får chansen; och, som jag nämnde i mitt svar på den tredje frågan ovan (om att få stöd från dina team), överväg att konsolidera till färre och färre styrelser, för att komma närmare och närmare en verklig end-to-end processvy för varje större process i din organisation.
För det andra, för projektcentrerade miljöer, lyft upp begreppet WIP-mål till projektnivå och bedöm om lägre volymer av samtidiga projekt resulterar i en högre genomströmning av projektavslutningar (ledtråd: det är ytterst sällsynt att en lägre WIP i ett projekt inte resulterar i en högre genomströmning - jag har bara sett det en gång, och det var efter en aggressiv minskning av WIP i ett projekt som helt enkelt gick lite för långt).
För det tredje kan du överväga att tillämpa koncept från Critical Chain Project Management som ett utmärkt sätt att hitta optimala nivåer för projektets WIP (läs mer om Critical Chain Project Management i min nya bok, The CIO's Guide to Breakthrough Project Portfolio Management).
F: Hur mäter du WIP i fasen före utvecklingsarbetet?
S: Jag tycker om att identifiera arbete i "föregående faser" som olika -korttyper på samma planhalva, med en enkel ToDo/Doing/Done-konstruktion. På så sätt får vi en verklig bild av teamets totala WIP-nivåer och kan till och med se vilka funktioner eller underteam som är närmare disciplinen med en enda uppgift än andra, och sedan be dem dela med sig av hur de har uppnått detta med de andra funktionerna eller underteamen.
Dessutom är det lättare att se om någon i t.ex. testteamet lider av ett hinder som en medlem av utvecklingsteamet kan hjälpa till med för att förbättra det övergripande teamflödet. Detta är förenligt med Scrum-principerna om ett integrerat team som blir bättre och bättre på det övergripande teamflödet genom effektivt samarbete och korsutbildning, samtidigt som individerna behåller sina primära roller och specialområden.
