Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

5 Sätt att hitta tid för kritiska IT-förbättringar

Publicerad By Mattias Skarin

Som IT-avdelning får du så många förfrågningar att du ofta måste lägga dina egna långsiktiga förbättringar på hyllan. När du äntligen får luft inser du att din tekniska plattform lämnade det "patchbara" stadiet för länge sedan - och nu brinner den.

Du behöver tid för att göra viktiga långsiktiga förbättringar - innan personalen tappar förtroendet och slutar. Detta är lättare sagt än gjort, eftersom det ofta krävs svåra avvägningar för att hitta tid för ledighet (utan att arbeta längre). Här är fem områden där du kan få den tid du behöver.

1. Förenkla uppskattningarna

Vi slösar ofta tid på att göra uppskattningar som är mycket mer detaljerade än vad som är nödvändigt för vår process. Genom att övergå från detaljerade till mer grovkorniga uppskattningar, t.ex. från story points till hinkstorlekar (dvs. S, M, L), kan vi spara värdefull tid och energi - som vi kan använda för att göra viktiga förbättringar.

Om du till exempel måste bestämma vilka funktioner du ska prioritera och (a) du inte behöver uppskatta alla berättelser bakom funktionen för att få en uppfattning om dess storlek och (b) du gör ett avvägningsbeslut för en liten uppsättning funktioner, fråga dig själv: Vad är det enklaste sättet att bestämma prioritering?

En uppskattningsteknik som frigör lite välbehövlig tid är att ta hänsyn till den ansträngning som krävs för att utveckla en funktion som inte varierar mycket (inte mer än 2-3x ansträngningen), medan marknadsvärdet för samma funktioner varierar mycket mer (någonstans mellan 10-100x marknadsvärdet).Anledningen till denna uppskattning är naturligtvis att göra en satsning på långsiktiga förbättringar.

2. Minska den tid som går åt till framtida analyser

Din ledningsgrupp ombeds ofta att ge rekommendationer för berättelser och projekt som planeras flera månader framåt i tiden. Som en tumregel kan man säga att det finns goda skäl att sluta lägga tid på detaljerad analys och design för projekt som planeras för sex månader eller längre fram i tiden. Även om projekten faktiskt blir verklighet kommer analysen och designbesluten troligen att behöva ses över när utvecklingen ändå inleds.

Rekommendationen för kompromisslösningar: Det är bättre för din ledningsgrupp att investera tid i utbildning och kunskapsdelning än att analysera och utforma saker som kanske aldrig kommer att förverkligas.

Om du är osäker, fråga dig själv vilket beslut som kommer att fattas på grund av din analys. Om svaret är "för att få en budget", ge teamet ett enklare sätt att fatta det beslutet - som inte innebär att du behöver dra till dig dina ledande personer.

Ett sätt att förenkla budgetprocessen är att öka beslutshastigheten. Om du för närvarande gör prognoser för ett år kan du försöka byta till kvartalsvisa prognoser. Detta är vad Beyond Budgeting lär oss, och det är något jag rekommenderar alla agila företag.

Den andra metoden för att minska den tid som går åt till framtida analyser är att frikoppla innehållet från den faktiska finansieringen. Tänk på kostnaderna som storleken på din pipeline och innehållet som det som flödar genom den. Kostnaderna är ganska stabila eftersom de beror på ett fåtal faktorer (personalstyrka, lokaler och licenser), så det är lätt att uppskatta förändringen över tid. Genom att undersöka denna förändring kan du fastställa din budget. Innehållet kan bestämmas när arbetet når IT - du behöver inte uppskatta innehållet för att hitta din budget.

3. Förflytta analysen till affärsenheterna

Många idéer till nya funktioner bygger på produkter och tjänster som vi eller våra konkurrenter redan har.  Få är innovativa, störande eller ger kunden ett betydande mervärde. Om din plattform är brinnande och dina resurser är knappa finns det goda skäl att skjuta upp implementeringen av dessa funktioner för att få tid för kritiska förbättringar.

Tills du har en tydlig förståelse för hur en funktion skiljer din produkt från andra produkter ur ett marknadsperspektiv - eller ger mervärde ur ett användarperspektiv - bör du prioritera långsiktiga IT-förbättringar framför att bygga nya funktioner. Skicka tillbaka förfrågningarna till de affärsenheter som ansvarar för dem och be om förtydliganden.

Observera dock att om din produkt är mycket IT-intensiv, kommer även innovationen att vara det. I det här fallet kan mycket av behovsanalysen fortfarande göras uppströms, men mycket av affärsidén och lösningsdesignen måste ske i nära samarbete mellan affärs- och IT-avdelningen.

4. Stoppa stödet för marginella produkter

Varje system har funktioner och tjänster som används mindre ofta än andra. Om du kan identifiera dessa funktioner och tjänster kan du argumentera för att stödet för dem helt och hållet ska upphöra. Nyckeln är att göra en faktabaserad analys för att identifiera vilka funktioner du kan motivera att du inte stöder. Fokusera samtalet på hur man genom att lägga tid på långsiktiga förbättringar på avdelningen kan förbättra den totala intäkten, även om man riskerar att förlora marginella intäkter.

5. Bojkotta möten utan syfte eller agenda

Gör en pakt om att inte delta i möten som inte har ett tydligt definierat syfte eller en agenda. Säg till din personal att det är frivilligt, inte obligatoriskt, att delta i mötena tills plattformen är stabil. Boka i stället in en dag i kalendern varannan vecka för att ha en "hackdag för teknisk skuld".

Avslutande reflektioner

Detta är fem knep som du kan ha i rockärmen för att få lite tid över för att göra viktiga IT-förbättringar. Om du upptäcker att du gör dem till vanor kan det vara ett tecken på att du saknar något i ditt ledarskap.

I min nya bok Real World Kanban hittar du fler exempel på långsiktiga faktorer som försätter grupper i desperata situationer.

Relaterade inlägg

Skrivet av Mattias Skarin

Mattias Skarin coachar och utbildar ledningsgrupper och värdeflöden i Lean- och Agile-organisationer i hur man bygger och upprätthåller en konkurrensfördel i en global, snabbföränderlig miljö. Han är författare till boken Real World Kanban och medförfattare till Kanban and Scrum, Making the Most of Both.