Planview-bloggen

Din väg till smidighet i affärsverksamheten

Enterprise Agile Planning

Kostnadsberäkning Agile och FAQ om kapitalisering, del I

Publicerad By Marcus Klein

Vanliga frågor om agil kostnadsberäkning P1

För bara några månader sedan, vid det globala SAFe-toppmötet i oktober, tillkännagav vi lanseringen av en ny produktfunktion som gör det möjligt för Planviews kunder att automatiskt kostnadsberäkna Agile-teamarbete och därmed bättre kapitalisera Agile-programvaruutvecklingsinsatser.

Vad betyder detta, undrar du kanske? Vår lösning använder den kraftfulla kombinationen av Planview Portfolios och Planview AgilePlace för att sammanställa och översätta gruppuppdrag, arbetstid och pågående arbete till en konsoliderad, fullt granskningsbar redovisning av de faktiska kostnaderna för Agile. Med den här informationen kan Agile- och ekonomiledare nu förstå den verkliga effekten som deras Agile-team har på resultatet, genom att identifiera Agile-utvecklingskostnader för korrekt CAPEX- respektive OPEX-kategorisering. I slutändan säkerställer den här informationsnivån att agila team får den finansiering och det budgetstöd som behövs för framtida satsningar och eliminerar behovet av manuell rapportering och avstämning av tidrapporter, vilket gör att utvecklingstiden återgår till verksamheten. Häftigt, eller hur?

Eftersom det här är en lösning som förändrar spelet och en superny teknik (och fantastisk, vill jag tillägga) har vi samlat de vanligaste frågorna som vi har hört mest om - från SAFe Summit, vårt årliga kundevenemang Horizons och många möten med kunder och prospekt. I den här bloggen svarar vi på dessa frågor:

  • Hur förhåller sig detta med Agile-kostnader till kapitalisering av Agile-programvaruutveckling?
  • Hur exakt bestämmer/skiljer du CapEx från OpEx med Planview?
  • Varför inte använda story points för att fastställa Agile-kostnader?
  • Hur exakt måste tidrapporteringen vara (individ, team eller team av team) för rapportering/kapitalisering?

Så låt oss gå rakt på sak.

F: Hur hänger detta med Agile-kostnader ihop med Agile-programvaruutveckling?

S: Tidigare har kapitaliseringsprinciperna anpassats väl till vattenfallsfaserna. Det kan finnas osäkerhet kring hur du kan tänka kring din aktiveringspolicy i förhållande till Agile- eller Lean-team som inte använder den klassiska fasindelade metoden för projektledning.

Det finns ingen anledning att känna att du inte kan kapitalisera bara för att du följer en annan metodik.

Medan organisationer fortsätter att använda vattenfall i vissa delar av verksamheten har andra delar av verksamheten övergått till agil leverans. Det är dags att erkänna detta skifte inom finanssektorn och ta reda på hur man kan ändra sättet att beräkna kostnader. Så länge du har en tydlig policy för att identifiera vilka funktioner som är berättigade till aktivering, kan du med hjälp av Agile-kostnadsberäkningar direkt överföra aktivering av Agile-arbete i Planview. Det är lika enkelt som att låta dina team flytta kort på en Kanban-tavla. Mer om detta nedan!

Jag skulle gärna vilja gå in mer i detalj på just detta ämne här, men jag har inte tillräckligt med ord för att göra det. Jag rekommenderar att du läser vår e-bok för att få veta mer. Men i ett nötskal kan du se hur vi lär våra kunder hur de kan tänka om när det gäller traditionell kostnadsredovisning för att anpassa sig till agila leveranser, med hjälp av Kanban.

Snabbare utvecklingscykler genomströmning av kapital.

F: Frågan ovan leder vanligtvis till nästa fråga: Hur exakt bestämmer/skiljer du CapEx kontra OpEx med Planview?

S: Först och främst måste du ha ett samtal med finansavdelningen. De kommer att ge riktlinjer för vilka funktioner som kan aktiveras och vilka som inte kan aktiveras.

Med hjälp av bilden ovan kan aktiviteter som utförs innan utvecklingen påbörjas (kolumnen Plan) inte aktiveras och bokförs som kostnader eller Opex. När det övergripande funktionskortet (som är markerat som aktiverbart) flyttas till ett körfält för pågående utveckling signalerar detta att utvecklingen har påbörjats och att du kan börja aktivera kostnaden (CapEx). Eventuella tillhörande barn- eller berättelsekort kan skrivas med versaler, och versaler upphör när det övergripande funktionskortet flyttas till "done".

Med Planviews lösning fylls tidtabellen i automatiskt, och de aktiverbara funktionerna och de sammanhängande berättelserna kategoriseras också automatiskt.

F: Varför inte använda story points för att fastställa Agile-kostnader?

S: Ur vår synvinkel är en punkt en representation av komplexitet, inte tid eller ansträngning. Att säga att något är en berättelse med 3 poäng betyder inte att det är 60% av ansträngningen för en berättelse med 5 poäng. Teamen har också olika definitioner av poängvärden, vilket gör det svårt att sammanföra dem mellan teamen.

F: Om det inte är story points måste det vara manuellt ifyllda tidrapporter, eller hur?

S: Nej, du behöver inte längre kräva att personalen fyller i tidrapporter manuellt. Även om du fyller i tidrapporter varje dag är det inte lika exakt som du förväntar dig. Tidsrapporter är i allmänhet inte 100% korrekta till att börja med:

  • Daglig komplettering: 66% korrekt
  • Slutförande varje vecka: 47% korrekt
  • Mindre än en gång i veckan: 35% korrekt

Låt teamen arbeta med det arbete de måste leverera till verksamheten och låt tidsuppföljningen ske i bakgrunden.

F: Hur exakt måste tiden vara (individ, team eller team av team) för rapportering/kapitalisering?

S: Traditionella metoder innebär att personer måste fylla i tidrapporter manuellt, vilket i hög grad beror på personens minne (se statistik ovan).

Vår automatiska beräkning utnyttjar den historik som sparas från varje korts aktivitet när den uppdateras av teamet. Resultatet är en automatiskt ifylld tidtabell som representerar vad som har flyttats genom Planview AgilePlace Kanban-brädan och levererats. Även om en person i teamet inte är lika vanemässig som de andra medlemmarna i teamet bör insatsens väsentlighet återspegla de åtgärder som vidtas i hela teamet.

Automatisering kan fortfarande ha kontroller och balanser för att öka förtroendet för uppgifterna. Dessa förfaranden kan tillämpas på obestämd tid eller under en viss tidsperiod tills förtroende har uppnåtts. Om du går igenom dessa alternativ tillsammans med finansavdelningen kan du hjälpa till att fastställa en process som fungerar för alla, och alla är möjliga med Planview.

  • I miljöer med hög styrning fylls tidsredovisningen automatiskt i av teamets/teammedlemmens naturliga aktivitet, men organisationen kan be varje teammedlem att granska, underteckna och skicka in sin tidsredovisning. I den här miljön kan cheferna också granska och godkänna, eller så kan tidsredovisningen ställas in så att den automatiskt godkänns när den undertecknats av teammedlemmen.
  • I styrningsmiljöer som ligger i mitten av vägen fylls tidsredovisningen i på samma sätt och undertecknas automatiskt av teammedlemmen, men det kan krävas att en teamledare eller chef granskar och godkänner den varje vecka eller månad för att se till att den är korrekt.
  • Miljöer med låg (eller ingen) styrning kan automatiskt fylla i, signera, godkänna och kostnadsberäkna tidrapporter utan att det krävs någon manuell granskning.

Håll ögonen öppna för nästa blogg där vi svarar på fler frågor om hur man kostnadsberäknar Agile och Agile mjukvaruutveckling. Under tiden kan du ta en titt på hur Planviews lösning gör detta automatiskt på i denna korta demonstration.

Relaterade inlägg

Skrivet av Marcus Klein VP, produkthantering

Marcus Klein är chef för produkthantering på Planview och fokuserar på att leverera innovativa, marknadsledande lösningar inom portfölj- och arbetshantering. Han samarbetar dagligen med kunder och potentiella kunder och tar hänsyn till industritrender och marknadsförhållanden för att utforma och leda produktriktningen, utveckla erbjudanden och definiera funktionella lösningar. Marcus fokus och huvudsakliga expertisområden är att koppla ihop portföljhantering med agila och samarbetslösningar (inklusive Projectplace och LeanKit), analys och rapportering, LeanKit och Lean and Agile Delivery-lösningen. I sina tidigare roller ledde Marcus produktlinjerna Planview Enterprise och Troux, samt tog fram konvergens av portföljer med lanseringen av Planview Enterprise One.