Agilt ledarskap - våga släpp kontrollen

Är det mycket snack och liten verkstad när det gäller det agila ledarskapet av idag?

Det är många organisationer som pratar om att vara agila och många anser nog att de arbetar agilt, men de får inte riktigt ut den fulla potentialen av arbetet. Det beror ofta på att delar av organisationen, oftast utvecklingen, bedrivs agilt och övrig verksamhet inklusive ledning och styrning bedrivs på annat sätt. Så länge det inte kuggar i på rätt sätt, där hela organisationen arbetar agilt, kommer det inte att få någon större effekt. Men det är lite läskigt för ledningen att släppa kontrollen.

Letting go

Det är ju lättare att göra som tidigare och fokusera på långsiktiga detaljmål som lätt kan kontrolleras och följas upp. Men är det rätt mål och följs rätt saker upp? Sannolikt inte. Vi måste börja tänka annorlunda, mer målsökande utifrån våra övergripande mål som är kopplade till affärsplan och vision. Det är bättre att ta fram en kortsiktig korrekt plan än en långsiktig felaktig, vilket ofta är fallet eftersom verkligheten är väldigt snabbrörlig och svår att förutse.

Ett förhållningssätt är att vara målsökande i stället för målstyrd. Detta kan anammas i stort sett alla situationer och leder till ett annat tänkande och ett annat sätt att leda och styra en verksamhet. Vi måste inse att en plan som inte är detaljerad inte är detsamma som att en plan inte finns. Det viktiga är hur vi styr mot slutmålet och att rätt detaljer hamnar inte i planen utan i resultatet, det vill säga fokusera på rätt saker. Självklart ska det i sammanhanget nämnas att en övergripande karta ska finnas som visar vart vi är på väg, och att detaljeringsnivån ökar när tidshorisonten blir kortare.

Vi måste börja lita på medarbetarna och att de gör rätt saker. Ledningen ska sätta vision, strategi och mål som medarbetarna arbetar mot. Med rätt satta mål, och med rätt vision, kan vi släppa medarbetarna fria att leverera det de är tillsatta att göra. Som ledare ska vi stötta och coacha dem så att rätt effekter uppstår. Våga släpp kontrollen, och se till att medarbetarna har rätt förutsättningar att leverera. Är det inte så att vi har de medarbetare vi förtjänar, och medarbetarna ska ha de chefer och ledare de har rätt till.

Om du och din organisation vill vara agila, måste du och era kollegor leva som ni lär och gå före med ert arbetssätt. Det måste finnas en röd tråd i hela organisationen där ledningen har ansvaret att denna tråd tas fram, utvecklas och efterlevs.

När det gäller uppföljning måste vi börja följa upp rätt saker, och fundera på om det är själva arbetet eller resultatet som ska följas upp. Det naturliga bör vara att följa upp att avsedd effekt uppstått. Frågan som nu dyker upp är förstås effekt för vem, och hur definieras denna nytta? Det enkla svaret är kunden, vilket de flesta nog håller med om. Men vem är kunden och finns det flera kunder? Ja sannolikt. Ett sätt att ta reda på vilka kunder vi har är att ta fram en customer canvas för de olika kundsegmentet och därigenom börja förstå kunden.

För att kunna göra en relevant uppföljning krävs att det finns något att följa upp mot, det vill säga ett utgångsläge, en baseline. Det är av stor vikt att ta fram denna baseline i god tid för att uppföljningen ska vara både relevant och möjlig. Värdena som uppföljningen görs emot behöver ständigt förnyas vid förutbestämda tidpunkter, varvid ständigt aktuella uppföljningar kan göras.

För att fokusera på rätt saker finns det företag som har avskaffat årsbudgeten. De tar istället fram månadsvisa planer som är aktuella och lättare att förutspå och att agera mot. Självklart kan uppföljningen sedan göras på valfri period såsom månad, halvår eller år.

En viktig beståndsdel i ett agilt arbetssätt är att arbeta med ständiga förbättringar. Det är ett sätt att tänka och därmed våga släppa kontrollen. Det är bättre att göra rätt saker fel än att göra fel saker rätt.

Det var ett antal frågeställningar ovan som behöver besvaras. Den slutliga frågan blir nu om du harsläppt kontrollen och vågar vara agil.

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.

Så undviker du surdegar

Visst har väl du också suttit med ”surdegar” kvar när projektet är slut? Aktiviteter som aldrig verkar ta slut. Ingen är ansvarig samtidigt som alla är inblandade och tiden bara rinner iväg utan att aktiviteterna blir färdiga. Till slut är det någon som tar tag i problemet och jobbar dedikerat med uppgiften så att den blir löst och när någon väl tog sig an uppgiften så gick det ganska snabbt att lösa den.

Innan ”surdegen” har hunnit lösas har projektets pengar tagit slut, projektets mottagare är sur för att de inte har fått utlovat resultat på utsatt tid och projektmedlemmarna är missnöjda för att de inte kan komma vidare till nya uppgifter. Detta är det sista man kommer ihåg från projektet och att man har gjort en mängd bra saker under hela projektet är bortglömt. Även om i stort sett hela projektet var klart i tid och höll kostnadsramarna så mäts man på problemen i slutet.

Varför har inte dessa surdegar lösts tidigare inom projektets ramar?

Ofta får man svaret: Då är det andra aktiviteter som inte hade blivit löst och det var fel på tidsuppskattningen, projektet hade för liten budget och för kort tidplan. Andra tycker att ”surdegarna” inte var så viktiga att lösa. Andra personer bryr sig inte då det inte är deras problem.

Varför har man då lagt tid på att till slut lösa ”surdegen”?

Jo, för att det finns en beställare som vill ha problemet löst!

Surdegarna dyker inte bara upp i slutet utan har ofta funnits där hela tiden men har varit svåra att lösa. Orsaken till att de inte lösts beror sällan på att de rent teknisk har varit svåra utan beror oftast på helt andra faktorer: Otydlig målsättning, otydligt ansvar, olika viljor men även tvetydiga krav eller motstridiga krav och att man inte har sett problemen i tid.

Hur gör man då för att lösa surdegarna innan de blir surdegar?

För att undvika surdegar finns det tre saker som är viktiga att tänka på:

1. Starta projektet med rätt förutsättningar

  • Problembilden behöver vara tydlig och kommunicerad. Det räcker inte med att ”alla vet” vad som inte fungerar utan här måste man våga skriva ner och kommunicera inom hela projektet vad man skall lösa.
  • Målsättningen med projektet måste vara tydlig. Med givet problem vad skall man åstadkomma i projektet så att alla har samma målbild inom projektet, annars blir det lätt olika viljor som drar åt olika håll.
  • Rätt medlemmar i projektet. De som är involverade i projektet måste ha rätt kunskap, vilja och mandat att lösa problemet. Projektledaren måste våga kräva att rätt resurser finns i projektet om inte så kommer vissa problem aldrig bli lösta.

2. Identifiera kritiska risker tidigt för att ha så lång tid som möjligt att lösa de svåraste problemen

  • Dokumentera riskerna så att alla kan ta del av dem.
  • Kommunicera riskerna i projektgruppen för att få flera olika perspektiv på hur man skall lösa dem. Kollektiv intelligens är överlägsen individuell intelligens.
  • Upprätta specifik handlingsplan för de mest kritiska riskerna och följ upp kontinuerligt.

3.”Early warning”. Identifiera potentiella surdegar tidigt och öka fokus på dem för att de inte skall växa sig stora

  • Genom att bryta ner projektet i olika delleveranser med tydliga målsättningar är det lätt att tidigt identifiera om något är svårare och tar längre tid att lösa än planerat.
  • Jobba intensivare med de eventuella punkter som inte lyckas bli klara inom ramen för respektive delleverans.

Om man jobbar med dessa punkter tidigt i projektet ökar möjligheterna att projektet även går bra i slutet, inte bara i början. Ofta är det jobbigt och svårt att göra rätt från början men det lönar sig i slutet.

”Surdegar” som hittas tidigt är bra ”surdegar” för dom har man möjlighet att göra något åt istället för ”surdegar” man sitter med i slutet, de är bara problem!

Är du intresserad av projektledning och styrning? Läs tidigare bloggposter på temat:

Styrgruppen ansvarar för misslyckade projekt av Johan Oldmark

Styr mot den fjärde dimensionen av Thomas Wahlberg

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.

Att gräva guld med Scrum

Det är lätt att vilja älska agila metoder. Rätt tolkat erbjuder de en miljö som lösgör kreativitet. Nyttobringande kreativitet skapar lösningar som befinner sig inom ramen för de högst prioriterade behoven. Vem vill inte ha det?

Som en bland flera lättrörliga metodiker är Scrum rejält i ropet men samtidigt konstaterar många det mätbara: Metodiken levererar för sällan de gröna skogarna och guldet uteblir. Det är ögonbrynshöjande att trots etablering av driftiga Scrum team, en lång backlog, burndown charts och retrospektiv så inträffar inte magi.

Var är då stålarna?

Det finns flera ställen att leta efter dem. De flesta börjar med att peka fingret på metodiken och på dem som är närmast den - Teamet. Sedan höjer man blicken och inser att Scrum inte låter sig implementeras lätt om inte ledningen ger sitt fulla stöd och skapar organisatoriska förutsättningar för det agila arbetet. Många väljer att ta hjälp av en yttre betraktare för att kunna se den större bilden. (Kanske står ni precis inför ett sådant val?)

Dessa kan ge en bit av svaret men det finns en tredje väldigt viktig del, som många antingen glömmer eller inte förstår den fulla betydelsen av.

Många scrumprojekt bedrivs på fullt allvar utan någon operativ och närvarande produktägare.

Man bedriver alltså sin utvecklingsverksamhet utan tillgång till en nyckelperson med hög verksamhets- och produktkompetens, förmåga att förmedla visioner och skapa tydliga mål och delmål, förmåga att se på produktens hela livscykel, förmåga att skapa rätt sammansatt referensgrupp, förmåga att tillsammans med sin referensgrupp skapa sammanhållna leveranser, vilja att ta ansvar för leveransen och dess kvalitet, förmåga och vilja att administrera produktbacklog disciplinerat, tillgänglig dagligen för frågor och prioritering, förmåga att driva frågor både internt och externt, förmåga att beskriva både funktionella och icke-funktionella behov som sprintmål, förmåga att diskutera olika lösningar samt förmåga att sätta gränser.

På ren svenska betyder det att det inte finns någon som kan definiera maximalt värdeskapande sprintar. Är det klokt? Eller är det helt enkelt så att det är svårt, på gränsen till omöjligt att hitta dessa egenskaper i en enda fysisk människa som redan innehar en heltidstjänst?

Enligt Scrum ska någon från produkt-/affärs-/verksamhetssidan ha denna roll, samtidigt som denna sida traditionellt sällan har behövt agera operativt på dessa nivåer. Nya krav ställs alltså på redan högpresterande och överbelastade systemägare eller produktchefer. Plötsligt förutsätts dessa produktägare vara förstklassiga kravställare, samtidigt som verksamhets- och kravanalytiker inte längre hittar sina naturliga arbetsuppgifter. Vad blir skillnaden mellan att förvalta backlog och att förvalta högnivåkrav?

Traditionellt har IT-projektledaren varit leveransansvarig till allas belåtenhet. Inom Scrum har man ingen projektledare. Ingen som planerar, dikterar tempot, följer upp, sätter gränser och rapporterar. Inte på det traditionella viset. Så nu får även styrgruppen problem. Styrgruppens traditionella mekanism är ju att styra och tyvärr inte sällan tillbaka till vattenfall. Där det är tryggt, kontrollerat och liksom inte värre än förut. Risken ökar att projektledarrollen cementeras, utvecklarna får köra på känn och fortsätter att sakna sin beställare. I bästa fall behåller man sprintarna och tavlan, för syns och vanans skull.

Det blir mycket svårt att upprätthålla skenet av ständigt lärande om en enskild komponent med så centrala arbetsuppgifter som produktägaren inte förmår, får, hinner eller vill göra allt som vederbörande borde i den operativa verksamheten. Det är ett garanterat sätt att ge Scrum dåligt rykte.

Produktägare är en oerhört viktig del i treklöverstrukturen (Team, Produktägare och Scrum master) med en ovanlig kombination av förmågor som helst ska innehas av en enda person per produkt, men som inte alltid är lätt att hitta inom den befintliga organisationen. Jag är fullt övertygad om att den kan skapas i alternativa former under olika perioder beroende på förutsättningar som företagsstorlek, organisationskultur och naturligtvis hur länge verksamheten har existerat i sin nuvarande form.

Jag tycker att ni inte ska vara rädda för att gräva där ni står. Vem vet om ni inte hittar nya guldägg?

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.

Styrgruppen ansvarar för misslyckade projekt

Vi är många som har erfarenhet av större IT-projekt som i någon mening stöter på problem och avviker från budget, tidplaner, förväntad kvalitet och/eller funktionalitet! Inte sällan blir det en fråga om vem som bär ansvaret. Men vilket ansvar vilar på projektledaren/projektledningen och vilket ansvar vilar på affärsledningen/styrgruppen för dessa avvikelser?

I grund och botten har naturligtvis projektledaren det operativa ansvaret för att driva projektet utifrån givna direktiv. Samtidigt kan vi ofta se att avvikelser från förväntat resultat inte enbart beror på brister i den operativa projektledningen.

Vår erfarenhet är att många projekt skulle kunna bli betydligt mer framgångsrika om rollerna mellan projektledningen och styrgruppen fungerade på ett bättre och mer professionellt sätt.

Det finns allt för många exempel där ansvaret för projektavvikelser till stora delar får tillskrivas bristande styrgrupps- /affärsledningsarbete.

Alla IT-projekt som startas skall ha ett tydligt syfte och mål. I de allra flesta fall är huvudsyftet att antingen spara kostnader/öka effektiviteten (defensiva IT investeringar) eller skapa nya affärsmöjligheter och öka intäktsgenereringen (offensiva IT investeringar). 

Under ett projekt är det av stor vikt att aldrig tappa bort det övergripande perspektivet – vad är den förväntade effekten av projektet?

Vår erfarenhet är att många organisationer allt för ofta tappar bort eller i vart fall tappar fokus på detta perspektiv när IT-projektet väl startat. Uppföljningen och styrningen blir allt för projektintensivt där projektledaren utifrån sina initiala projektmål planerar, styr och följer upp arbetet utifrån givna specifikationer, tids- och budgetramar.

Således är det av stor vikt att den styrgrupp (eller affärsledning) som finns för projektet kontinuerligt återkopplar det övergripande syftet med projektet och säkerställer att framdriften och styrningen av projektet hela tiden främjar de övergripande effekt- och affärsmålen.  

Normalt är också att behoven hos affärsverksamheten förändras under projektets gång. Det gäller framför allt när projekten är stora och genomförs under en längre tid. Behovet av och kraven på affärsledningen/styrgruppen blir då extra stor, eftersom det är styrgruppen som har det yttersta ansvaret att direktiven och förutsättningarna som ges till projektledaren kontinuerligt speglar förväntningarna på resultatet.

Ett viktigt motsatsförhållande att komma ihåg är också att i början av större projekt, när många av de styrande besluten tas, är kunskapen som ligger till grund för många beslut generellt begränsade.  Ju längre in i projektgenomförandet man kommer, desto tydligare blir förutsättningarna och konsekvenserna av tidigare beslut.

Kraven på en ”agil” affärsledning/styrgruppsarbete är således stor då vi nästan alltid kan förvänta oss att förutsättningarna för projektet kommer att förändras över tiden.

Att sitta med i styrgruppen till ett större IT-projekt ställer således höga krav på engagemang, kunskap och erfarenhet. Styrgruppsarbete är till stora delar en profession som rätt hanterat skapar goda förutsättningar till ett framgångsrikt projekt.

Tyvärr är verkligheten ofta sådan att styrgrupperna till större IT-projekt tenderar vara för stora räknat i antalet styrgruppsmedlemmar, medlemmarna lägger inte tillräckligt med tid/engagemang och har otydlig ansvarsområden. Det resulterar i en oförmåga att ge projektledare tydliga direktiv och också ställa krav på uppföljning. Och inte minst också vara beredd på att hantera de konsekvenser som ändrade projektdirektiv medför.

Så likväl som man i många projekt stöttar projektledaren och hans projektteam med extra kompetens och erfarenhet så borde fler organisationer också titta på hur man utvecklar sin förmåga att stärka och förbättra förutsättningarna för styrgruppen/affärsledningen att verka professionellt och effektivt. Allt i syfte att säkra framgångsrika IT-projekt.

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida

Styr mot den fjärde dimensionen

Alla vet att det är viktigt för ett projekt att ha kontroll på tid (T), kostnad (K) och kvalitet (Q). Dock gör allt för många likhetstecken mellan att hållen budget och tidplan är detsamma som ett lyckat projekt.

Är TKQ i förhållande till ursprunglig plan en garanti för ett lyckat projekt? När är ett projekt lyckat? Är det att hålla ursprunglig budget och tidplan framtagna i början av projektet?

Är det inte så att ett lyckat projekt levererar avsedd effekt och nytta till berörd verksamhet, vilken kan mätas i både direkt och indirekt nytta, vilka tillsammans ska vara större än projektets kostnad? Vi får då en utökad TKQE, där E står för Effekten. Det är denna effekt vi ska följa upp och styra projektet mot, liksom att hela tiden hålla business caset uppdaterat med aktuella siffror.

Nyckeln är att styra projektet mot denna effekt och att följa upp densamma kontinuerligt. Haken är att det kan vara både svårt, kräver bland annat en annan projektorganisation med beställaren involverad, och i vissa fall även oönskat då berörd verksamhet synliggörs, vilket kan vara besvärande för de berörda även om det för hela organisationen ger positiva effekter.

Men har då TKQ spelat ut sin roll? Nej, att i projektplanen ta fram en TKQ-prioritering bör självklart göras och kan vara till stor hjälp vid prioriteringsbeslut. Det är lika självklart att ta fram en budget och ett genomarbetat business case.

Ett annat problem med klassisk TKQ är att dess värden och principer sätts i samband med projektplanen i början av projektet. Sedan styrs projektet mot dessa TKQ-mål, det vill säga projektet är målstyrt. Problemet som fler och fler upptäcker är att verkligheten förändras, och det i allt snabbare tempo, och därmed även verksamhetens krav och behov. Vi måste därför kunna styra projektet mot en rörlig kravbild, det vill säga målsökande i stället för målstyrt och med andra ord ett agilt förhållningssätt. Med ett målsökande projekt kan inte enbart TKQ användas som styrmedel, utan en fjärde dimension, Effekten, måste läggas till så att vi får TKQE att styra mot.

Vem är ansvarig för det här arbetet, självklart är det projektledaren. Denne kan i och för sig använda sig av en projektekonom eller liknande som stöd, men inte frånsäga sitt ansvar. Styrgruppens ansvar blir då att säkerställa att effekten verkligen blir av i organisationen.

Att styra mot en fjärde dimension kräver att styrgruppen och intressenterna finns med redan från början och ser till projektets och organisationens bästa. Ett problem är att effekten kopplas ihop med kommande budget. Dessa måste frikopplas för att få ett samarbetsklimat som gynnar hela organisationen och möjliggör nyttohemtagningen.

Det finns olika metoder för att ta fram business case och för att följa upp effekter/nyttor, och det är inte viktigt vilken metod som används bara man väljer någon och är konsekvent i användandet.

Slutsatsen blir att vi ska arbeta fram TKQE och där fokusera på styrning och uppföljning på Effekten.

I del två av denna artikel kommer vi att skriva om uppföljning av effekten efter det att projektet avslutats.

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida