I dagens tid av digitala störningar är förmågan att snabbt leverera värde avgörande för en organisations överlevnad. Detta behov är en av orsakerna till att Agile blir alltmer populärt, med sin förmåga att leverera snabbare och möjliggöra snabbare feedbackcykler med kunderna. Agilitet har kommit långt från den tid då det var en marginell ideologi som var reserverad för avvikare och personer som tänkte utanför boxen. I dagsläget använder sig topporganisationer runt om i världen av Agile i stor skala och överger den traditionella projektfinansieringsmodellen.
Det finns en aspekt av Agile som det talas mycket om nuförtiden men som relativt få människor verkligen förstår -produktmodellen. Detta tillvägagångssätt används för att decentralisera beslutsfattandet och för att närmare och konsekvent anpassa den digitala resurskapaciteten till de affärsområden genom vilka företaget levererar värde till kunderna. Det är ett steg bort från den traditionella projektfinansieringsmodellen, där beslutsfattandet centraliserades genom en långsam och kostsam process där man uppskattade allt potentiellt arbete och tillfälligt tilldelade delade resurser till godkänt arbete, mot en mer Lean Portfolio Management stil för planering, finansiering och leverans av arbete.
Innan vi kan förstå produktmodellen och dess fördelar måste vi först granska projektfinansieringsmodellen för att förstå varför den uppstod och vilka utmaningar den skapar.
Problem som är förknippade med modellen
När du beskriver Agile för personer som har arbetat länge inom IT är det inte ovanligt att du får höra: "Men det var ju så vi brukade arbeta!". De har inte fel. Före 1990-talet var IT-avdelningarna mycket mindre än i dag eftersom datoranvändningen var begränsad till stordatorer och andra stora centrala enheter. På 1990-talet uppstod PC-baserade klient-server-system, särskilt sådana som levereras via en webbläsare. Plötsligt kunde alla avdelningar på ett företag skapa kundprogramvara med hjälp av relativt enkla verktyg - och de gjorde det. Du såg servrar växa upp överallt - under skrivbord och i städskåp. Det var spännande, men det skapade en del problem.
CFO:erna märkte alla dessa utgifter och insåg hur ineffektiva de ofta var. Att varje avdelning köpte en egen kraftfull server för att köra ett system var inte det bästa sättet att använda pengarna. Alla dessa datorer som fanns utspridda på kontoret var en säkerhetsrisk - massor av känsliga data som kunde stjälas eller förloras om en hårddisk gick sönder. Arbetet utfördes ofta på ett inkonsekvent sätt och varje avdelning anställde sina egna programmerare, vilket gjorde support och integration till ett verkligt problem. IT centraliserades alltså på nytt. Fler företag inrättade centrala IT-avdelningar under informationsdirektörer, som ofta rapporterar till ekonomichefen.
I denna modell bestämmer finansavdelningen varje år hur mycket de vill spendera på teknik med tanke på företagets ekonomiska situation och "beskattar" affärsenheterna med en del av sina intäkter för att skapa en central pool. Ledningsgruppen fastställer strategier som ska styra investeringsbesluten. I teorin väljs projekten ut utifrån dessa strategier för att fokusera resurserna på de högsta prioriteringarna för företaget som helhet. I praktiken är det oftast lokala prioriteringar som styr processen, och varje område arbetar med processen för att få "sina" pengar tillbaka.
Affärsanalyserna är anpassade för att skapa en vacker bild som får godkänt av finansministeriet. När arbetet väl börjar skiftar nästan allt fokus till att hålla IT-avdelningen ansvarig för hur väl de presterar i förhållande till uppskattningar som ofta justeras under planeringsprocessen för att få godkännande. Och det ursprungliga affärsvärdet som utlovades utvärderas sällan efter projektet. Framgång mäts i allmänhet med hjälp av projektledningens järntriangel: i tid, inom räckvidd och inom budget. Det spelar ingen roll om det utförda arbetet verkligen gav verkliga resultat för företaget.
Projektmodellen skapade ett antal problem som påverkade teamens sätt att planera och leverera innovation negativt.
Problemen med projektfinansieringsmodellen slutar inte där för organisationer där personer rapporterar till funktionella silos- vilket är vanligt i IT-organisationer - och där procentandelar av deras tid tillfälligt tilldelas olika projektgrupper. Detta skapar en orolig situation där flera projekt konkurrerar om samma resurser, det vill säga att personalen tilldelas mer än ett projekt. I en sådan situation argumenterar naturligtvis alla projektledare för att deras projekt är det viktigaste för företaget.
Som du kan föreställa dig skapar detta en svår arbetsmiljö som i slutändan skadar företaget. Det innebär att olika team inom samma organisation arbetar mot varandra för att uppnå sina projektmål, istället för att arbeta för att driva företaget framåt. Dessutom lämnar denna modell organisationen i ett konstant tillstånd av osäkerhet och instabilitet. Eftersom resurserna delas (och konkurreras ut) mellan flera projekt, får ett bakslag för ett initiativ en dominoeffekt som drabbar alla andra projekt.
Låter kontraproduktivt, eller hur? Det är det.
Förutom att den här modellen med delade resurser är instabil och oförutsägbar är den inte heller effektiv för att leverera kontinuerliga förbättringar. Människor dras ständigt från sina funktionella avdelningar och tilldelas olika projektgrupper. När de har fullgjort sitt uppdrag i ett team tas de bort och placeras i en ny grupp, och cykeln fortsätter. De är fast i ett övergående tillstånd och har varken tid eller incitament att investera energi i ständiga förbättringar. Med tanke på kraven på att hålla tid, omfattning och budget uppmuntras teamet faktiskt att inte fokusera på något annat än projektets framgång. Och det finns ofta en åtskillnad mellan dem som genomför projekt och dem som sköter drift och underhåll. Projektgrupperna behöver alltså inte ta itu med de problem som de orsakar nedströms. Det är ett recept för dålig kvalitet och teknisk skuld som inte alls uppmuntrar till förbättringar, utan snarare leder till dålig kvalitet och teknisk skuld.
I nästa del av denna serie ska vi titta på hur dessa problem hanteras i produktmodellen. Under tiden kan du lära dig mer om hur Planview stöder övergången från projekt till produkter genom att titta på demo eller ladda ner vårt whitepaper "Lean Portfolio Management for the Enterprise" för att se hur organisationer använder LPM för att hjälpa till med övergången till en produktcentrerad modell.
