I mitt inbitna och lätt nördiga intresse för projektledning reflekterar jag allt som oftast över den mycket grundläggande frågeställningen: ”Varför lyckas vissa projektleveranser medan andra, kanske till och med de flesta, inte gör det?”. Kan jag se något mönster som förklarar varför de lyckas? Finns det något som saknas i de initiativ som inte går lika bra? Definition av vad vi ska anse som lyckat får vi ta i ett annat blogginlägg.
Varför lyckas vissa projekt?
I mina egna leveranser tar jag mig alltid tid att fråga teamet vad vi gör bra och vad som kan bli bättre, helst löpande i så kallade ”retrospektiv” men i allra minsta fall i någon form av uppsamling mot slutet av en leverans. Ni som faciliterat eller deltagit på liknande sessioner kan säkert instämma i att många av diskussionerna kretsar kring vilka FÖRUTSÄTTNINGAR teamet har haft för att leverera det som efterfrågats, eller kanske oftare en brist på desamma.
Jag går tillbaka till gamla anteckningar från de många retrospektiv som jag själv faciliterat. Om jag då tillåter mig själv att förenkla och gruppera de vanligaste lärdomarna som brukar identifieras hittar jag två kluster: ”UTVECKLINGSPROCESS” och ”KRAVPROCESS”.
Hoppas du är med mig än så länge, för det är nu det börjar bli intressant!
Business Analyst äger och driver kravprocessen
Utkomsten av ett retrospektiv är att vi ska bli bättre. Därför definierar man således listor med förbättringar. På listan över förbättringar sätter vi gärna aktiviteter under rubriken ”UTVECKLINGSPROCESS” kring projektmodell och systemstöd, bättre lokaler eller tekniska förutsättningar. Här brukar vi vara relativt konkreta och uppfinningsrika. Det finns tydliga ägare, ofta Scrum master och projektledning.
Men under rubriken ”KRAVPROCESS” finner vi ofta generella aktiviteter som ”verksamheten måste definiera vad de vill” eller ”kraven behöver bli tydligare/mer detaljerade”, ibland ekar det helt tomt. Det finns sällan en tydlig ägare för dessa, eller möjligen någon med begränsad förmåga att göra någonting åt saken…
Minns jag tillbaka till de initiativ som gått riktigt bra så har det funnits både en välfungerande kravprocess och utvecklingsprocess, det räcker inte att en av dem fungerar. Faller kravprocessen kvittar det hur väl utvecklingsprocessen fungerar.
Det är just i kravprocessen Business Analysten (populärt BA) kommer in. BA´n äger och driver kravprocessen från ax till limpa och hjälper och utmanar er så att verksamhetens förändringsinitiativ levererar de krav som ger mest affärsvärde. BA´n hade varit en given kandidat till att äga de förbättringar som identifieras under rubriken kravprocess i övningarna ovan. BA´n är produktägaren och kravägarens högra hand och ofta oumbärlig hjälp i varje leverans. BA´n skapar förutsättningar för alla andra att göra sina jobb riktigt bra!
Det anses ofta ofint att inte veta exakt vad man vill ha ut från sina förändringsinitiativ, eller vad som ger störst värde. ”Man måste veta vad kraven är!” heter det. Men det är inte lätt att svara på det utan en välfungerande kravprocess och en gedigen verktygslåda. Vi på Stretch har respekt för att det kan vara svårt, det har vi alla erfarenhet ifrån. Vi är också säkra på att alla verksamheter kan leverera ännu mer affärsvärde i sina förändringsinitiativ med en skicklig BA! Nyfiken på hur vi menar? Kontakta oss på hej@stretch.se så berättar vi om hur andra grymma kunder gör för att lyckas.
