Produktägarskap handlar om relationer

23 09 2015

När man tänker på produktägare och produktägarskap, så hör jag ofta att man tänker på marknads- och trendanalys, arbete med användarbehov och affärsnytta, arbete i utvecklingsteam och kanske acceptanstest. Att strukturera och grooma backlogen, sätta visioner och mål, följa upp och kommunicera dessa med teamen. Skriva user stories och klarkriterier kanske.

I teorin var det nog så Scrum-skaparna tänkte.

Efter att i många år ha arbetat både med och som produktägare så har jag insett att de delarna är bara en mindre del av rollen och uppgiften.

En produktägares viktigaste uppgift är att skapa och underhålla relationer. Relationer med kunder, intressenter, slutanvändare, leverantörer och utvecklingsteam. Om du som produktägare undrar vad du ska prioritera idag, så ställ frågan – vem är viktigast att jag träffar idag? (alternativt ringer upp eller kontaktar på annat sätt). För att höra hur de mår, hur det går, ge information om läget eller bara småprat.

Den andra viktigaste uppgiften är att kunna berätta en historia. Som produktägare hinner du sällan med att genomföra allt, leverera allt enligt plan eller förväntan. Men om du kan berätta din historia så är det mindre viktigt vad som faktiskt levererats. Mer viktigt är berättelsen om planen framåt, även när den är ytterst oklar, och om läget i teamet, även när det är kaos. En berättelse kan ha många hål, men det är produktägarens vardag. Du kommer inte ha koll på allt, alla siffror, alla detaljer jämnt. Men kan du berätta din historia på ett trovärdigt sätt så sköter du jobbet utmärkt.

Det kan räcka med en snygg powerpoint-presentation som lyfter fram små men ändå viktiga delleveranser så att det ser proffsigt ut. Eller att du använder ett språk som omgivningen gillar. Eller att du bara valt en bild som illustrerar något som är viktigt för mottagaren.

Framgång som produktägare handlar om att gå och ta den där after worken trots att du inte alls har tid eller har en enorm förkylning. Att du går och tränar ihop med någon chef som du kanske inte alls skulle umgås med annars. Att du åker till andra sidan stan för att luncha med den där leverantören då och då.

Detta leder till framgång för produktägare.

Backlog, user stories, produktvision, demos och allt annat metodiskt kan du delegera eller avsätta en dag i veckan för. Trots att det kanske var det du trodde att jobbet skulle handla om.

Stämmer det med dina erfarenheter?

Annonser




Tips för att närma sig intressenters visioner och mål: Nuläge

13 04 2015

Fick en fråga från nybliven produktägare som undrade om bra tips på hur man närmar sig intressenters visioner och mål. Här är några av mina tankar, även om det kan göras på 1000 olika sätt. Hoppas gladeligen på kommentarer och länkar till andra idéer och bra artiklar.

Vision
Kortsiktig eller långsiktig vision?  Beroende på det gör jag lite olika men gemensamt för dem båda är att jag vill bilda mig en konkret uppfattning om NUET först.  Genom att förstå och beskriva hur en produkt, tjänst, feature eller något annat fungerar just nu så uppstår visioner, det är iaf min erfarenhet.

En affärsstrateg föreslog just detta. Lägg 80% av tiden på att förstå nuet, och 20% av tiden på att förstå och beskriva framtiden så är du hemma. Det stämmer med min uppfattning.

Att beskriva nuet

Generellt gillar ju de flesta att visionera, brainstorma, tänka trender och fantastiska framtider. Att lägga tid på att undersöka nuet är inte lika populärt alla gånger. ”Har du verkligen tid med det här” är en vanlig fråga. Genom att timeboxa och återkomma till argumentet ”Om vi inte vet var vi är nånstans på kartan, hur ska vi då veta vilken riktning vi ska ta för att komma fram?”  så brukar jag få/ta mig tiden att beskriva.

Några verktyg och metoder:

1. Observationer

Hitta möjligheter att på plats observera hur dina användare, intressenter, målgrupp använder din produkt/tjänst just nu. Genom t.ex studiebesök eller att bjuda in en grupp som du ber genomföra en del uppgifter och titta på hur de gör. Detta går också virtuellt. Be din kund visa hur det ser ut på hans skärm på distans, att dema hur han jobbar, eller sätt upp user test miljöer genom t.ex http://www.usertesting.com/.  och liknande.

2. Inspelningar

Med hjälp av verktyg som t.ex http://www.clicktale.com/ och http://www.sessioncam.com/
 eller In product analysis kan du följa hur användaren rör sig genom applikationen. Ibland känns det långt borta att få köpa, installera ett sådant verktyg, men genom gratis trials och visa de som har pengarna hur bra det är så brukar acceptansen komma med tiden.

3. Enkäter & intervjuer

Lite annan sorts information får du genom att sätta upp enkäter på din webbplats, eller genom andra forum. Bästa insikten vid enkäter är generellt citaten snarare än vad man kryssat i för alternativ. Citat säger ibland mer än tusen ord om hur de uppfattar och använder din tjänst.  Se till att designa enkäten så att fria kommentarer blir naturligt. Vid intervjuer brukar jag försöka få dem att berätta snarare än beskriva. Berättelser från verkligheten snarare än ”vad tycker du”-frågor.  Nedan beskrivs närmare vad jag menar 🙂

http://incontextdesign.com/articles/dont-ask-your-customer-comic/

4. Sammanfatta genom scenarios

Beskriv det du lärt dig om NUET genom scenarios – visuella eller textuella.  Nedan är ett fiktivt exempel från verkligt projekt som kanske inte säger just dig så mycket, men visar hur ett scenario kan se ut. Hade jag varit designer hade det naturligtvis varit mycket snyggare, men jag har insett att bättre rita fult än inte alls..

Nu-scenario email Bild1

Ett textuellt scenario kryddat med känslor kan se ut så här:

Namnlös

Tack @soapui @readyapi för den emotionella insynen av viss del av målgruppen 🙂

Och så kan man göra långa mer eller mindre dramatiska berättelser som beskriver just din kunds upplevelse.

Det finns massor av exempel om du googlar på ”CX” som är det nya begreppet, eller ”customer scenarios” eller ”customer journey” mm.

Min poäng är att det behöver inte vara så proffsigt, snyggt eller ens strukturerat så länge som du beskriver din förståelse av nuet i form av scenarios med hjälp av bilder eller text, eller både och.

5. Value Prop Canvas

Mycket trevligt verktyg för att beskriva nuet. Genom att förstå och beskriva din produkts Value proposition blir det betydligt lättare att identifera vision. Vad är din produkts kärnvärde? Vad gör att dina kunder köper den och dina användare använder den? Vad är deras Gains och Pains när de använder produkten?  Läs mer och prova själv med dina intressenter.

value_proposition_canvas

Det finns ju många fler verktyg, detta var några av mina favoriter.

När du beskrivit nuet kan du fundera på framtiden, visionen. Och det får bli i nästa inlägg..





Produktägaren – domänexpert eller processguru?

3 03 2015

Efter ett samtal häromdagen om produktägarrollen på en organisation så började jag fundera igen över detta.
Vad är det för slags produktägare man ska tillsätta, om man nu som beställare, chef, processägare eller något annat vill ha en sådan roll i sin utvecklingsorganisation?

Är det den person som kan bäst om domänen man verkar i – försäkringar, marknadsföring, administration, kundservice etc? (kan ibland vara superanvändare).
Eller är det någon som är proffs på utvecklingsmetoder, systemutveckling, processer, användbarhet etc i allmänhet? Någon som levt och verkat i utvecklingsmiljöer.
Eller är det affärsägaren – den som faktiskt ansvarar för att affären eller verksamhetsnyttan går hem? Ofta en linjechef av något slag.

Jag har sett olika varianter på detta och naturligtvis finns inget rätt svar. Min slutsats är att oavsett vilken av dem man väljer så:

1. kommer den personen behöva ordentilgt avsatt TID – dvs bli av med andra uppgifter.

2. personen kommer behöva lära sig ordentligt något utanför hens normala zon. Är man domänexpert/superanvändare behöver man t.ex lära sig utvecklingsmetodik på riktigt. Är man process-proffs behöver man lära sig domänen och marknad. Är man affärsägare behöver man lära sig UX-metoder etc. Tid behöver ägnas åt detta och ibland investering i utbildning och liknande.

3. personen kommer behöva stöd av någon av de andra rollerna för att lyckas i sin produktägarroll. Processproffset kommer behöva enkel tillgång till superanvändare och domänexperter som kan vara med i designdiskussioner och delta i acceptanstest, dvs kunna ägna tid åt utvecklingen. Affärsägaren kommer behöva ett processproffs som kan fokusera på behov & kravställning, domänexperten kommer behöva en tillgänglig affärsägare för att kunna fatta affärsmässiga beslut etc.

4. personen behöver ett tydligt mandat – mer eller mindre, bara det är tydligt.

För den som sett en produktägarorganisation riggad på detta sätt, har troligen också sett de resultat man vill åstadkomma med agila metoder – dvs bättre time to market & bättre värde till kund

Tyvärr behandlas produktägarrollen i de flesta organisationer slarvigt. Man tillsätter någon som känns rätt, utan att ge den det stöd eller framför allt den TID som krävs för att få full nytta av rollen. Sedan säger man att man jobbar ”agilt” fast utvecklingsteamen och leverantörerna fortfarande inte har någon riktigt närvarande att kommunicera med utan kör sitt race som vanligt. Alternativt en alltför teknisk produktägare som inte uppmuntras till att kunna och faktiskt få ta ett större affärsansvar.

Om den ideale produktägaren, t.ex en affärsägare, helt enkelt inte KAN flyttas från sina ordinarie uppgifter, kanske är det bättre att hon medverkar som aktivt affärsstöd istället till någon annan utsedd produktägare – t.ex en superanvändare eller processexpert?

När jag sett produktägarrollen fungera så har det inte spelat någon roll vilken av ovanstående som varit produktägare, utan skillnaden har bestått i NÄRVARO, TID samt ordentlig backup på det område hen inte är expert i.

I den gamla metoden XP – Extreme Programming, föreslog man ration 1-1 av kodnära utvecklare och andra roller i teamet  t.ex som nedan:

Skärmavbild 2015-03-03 kl. 12.04.38

Process-stödet (t.ex en Scrum-master, teamcoach och liknande) finns inte i XP om jag minns rätt, men ofta behövs också en sådan roll något beroende på teamets storlek, uppgift och mognad.

Testaren har jag lagt till som en egen roll, beroende på teamets uppdrag och kvalitetsmognad behövs också en sådan. Testaren har jag också sett vara ett ovärdeligt stöd till produktägaren i fråga om både kravställning, acceptans, användningstest mm.

Detta är motsvarande heltidare. Dvs om man har en UX på 50% så borde också en av kodnära utvecklarna vara på 50%… för att hålla ration. Om du vill ”fördela” testaren eller UX:aren på 2 team på 50% vardera, har du också tänkt fördela en av utvecklarna på två olika team? Det hänger också på reell närvaro (fysiskt eller virtuellt) för att fördelningen ska fungera. Dvs en testare som aldrig är delaktig i utvecklingsteamet på riktigt, gör antagligen inte så stor nytta som hon skulle kunna.

Jag vill helt enkelt slå ett slag för XP igen och att alla som beslutar om produktägarskap tar sig en funderare på vad man vill uppnå. Räcker det med att någon får hatten Produktägare för att öka nytta, kvalitet och time to market?  Eller krävs helt enkelt en ny och mer seriös approach till det utvecklingsarbete som är av mindre teknisk art för att våra nya metoder ska löna sig?

Heja alla produktägare därute som gör sitt bästa för att få någonting gjort på sin lilla tid och kämpar för att hålla takten i analys, kommunikation, visionerande, utredningar, planering och uppföljning av utvecklingsarbete, acceptanstest, marknadsresearch, kundstudier….





Agilt, Iterativ & Inkrementell!

22 03 2013

Jag fick den här frågan från en kompis & student:

”Agile, Iterativ & Inkremell! Vi har pratat lite om det jag & några från klassen, och alla typ blandar ihop allt!
Vissa säger att tex Scrum är agilt, andra säger att det är ngt annat bla bla, jätte förvirrande :b det ända jag har
koll på är att RUP iaf är iterativt haha.”

Ska jag göra ett försök att förklara begreppen lite kort?  Jag gör ett försök..

Agile
Agile är ett sätt att tänka. Det är inte ett verktyg. Det är inte en metod. Det finns metoder som Scrum, Kanban, Lean Software Development som kan hjälpa dig att komma framåt. Du kan vara agil utan att använda någon metod alls. Du kan också vara agil med en gammaldags metod som RUP, eller vilken som helst annars. Det handlar om ditt sätt att se på projekt som en icke-förutsägbar händelse, och ditt sätt att se på verkligt samarbete (arbeta tillsammans), ständigt omfamna förändringar i omgivningen och hos dina kunder, kontinuerligt förbättra hur du och ditt team arbetar och samarbetar.

Det går att jobba enligt Scrum och inte alls vara agil, även om Scrum med sina regler om att inom en kort tid leverera fungerande programvara ofta hjälper till på vägen att bli agil.

Den här blog posten beskriver vad agile inte är  – med referenser till principerna i det Agila manifestet, som handlar om principer – inte verktyg & metoder.   http://www.tommycode.se/2012/12/what-is-agile.html?m=1

En gång delade jag några tankar om vad agilt är, på stapplande engelska..

http://blog.smartbear.com/software-quality/bid/224669/Ulrika-Park-Becoming-Agile

Iterativ

Iteration är ett annat ord för upprepning. Inom matematiken och i programmering handlar detta om att en funktion eller process åstadkommer något genom att upprepa tills ett önskat resultat uppnåtts.  (wikipedia nerkortat)

Ett annat ord är loop. Tänk dig ett flygplan som gör en loop. Sedan gör flygplanet samma loop igen. Det är den 2:a iterationen. Bilden nedan är ett gäng iterationer av samma flygplan.

Smoke-Loops-Flight-demonstration-Circle-Sky-300x187

Inom systemutveckling är det att utveckla samma funktion flera gånger tills den är tillräckligt bra.
Det kan också vara att genomföra samma projekt flera gånger tills det är tillräckligt bra att släppa till kund.

Säg att du skriver en uppsats om ett ämne. Du skriver en version rakt på tills den är klar. Sedan börjar du om och skriver samma uppsats en gång till. Du tar med dig saker från första versionen, kanske många meningar, men lägger till saker, tar bort saker, ändrar ord. Den andra versionen är andra iterationen. Skriver du den en tredje gång, har du gjort 3 iterationer.

Detta är något som glömts bort i många genomföranden av s.k agile.

Jag har varit med i ett par projekt där vi verkligen jobbade iterativt. Det vill säga – vi valde en funktion att bygga. Definierade vilka krav & testfall som skulle passera för att funktionen skulle kunna fungera någotsånär. Vi visade upp funktionen för beställaren/kravställaren. Sedan byggde vi samma funktion en gång till – byggde ut, snyggade till, förbättrade både bakom ytan (programkoden) och framför ytan (användargränsnittet). Ibland en tredje och fjärde gång.

Att jobba iterativt är att ALLTID bygga samma funktion minst 2 iterationer – 2 gånger.

Faktiskt så påstod även någon att även den förhatliga Vattenfallsmetoden var iterativ från början. Meningen var att man skulle driva sitt projekt enligt Krav – design – implementation – test – integration – leverans och sedan köra samma projekt en gång till och då göra det rätt och snyggt. Kanske borde kolla upp källorna på detta, men har för mig att jag sett bilder på en loop – där man går tillbaka till början direkt efter slutet.

Idén med RUP var också att vara iterativ. Dvs definiera krav (use cases), design, progammera, testa under en fas, sedan gör samma sak en gång till. Tyvärr dränktes den idén i för mycket annan information, regler & dokumentation så att jag har sett få RUP-projekt som faktiskt jobbat iterativt, även om jag har hört talas om dem som faktiskt gjort det.

Scrum är enklare och studerar man metoden noga kan man se att tanken är att iterera, loopa, över funktioner. Det har tyvärr också ofta dränkts i idén att man bara ska leverera snabbt snabbt. Att leverera snabbt är inte huvudfokus i principerna i det agila manifestet. Ingenstans sägs att man ska leverera snabbt. Men man ska prioritera fungerande programvara framför pappersprodukter (oändliga dokument som inte går att använda).

En ”sprint” i Scrum är INTE en iteration. En sprint är rätt och slätt en time-box på t.ex 2 veckor (aldrig mer än 4). Efter 2 veckor ska teamet visa upp resultatet för sina intressenter. Och bara fungerande programvara. Dokumentation, tankar, idéer och planer är oväsentligt. Huruvida man faktiskt tar samma funktion och itererar över den i nästa sprint, sägs inget om i Scrum, även om metoden kan tvinga fram det beteendet. Man hinner inte på 2 veckor göra så mycket ”lull lull”. Man måste ofta gå tillbaka till samma funktion nästa eller senare sprintar för att göra den värdig att sälja/använda.

Man kan säga att en sprint i Scrum kan vara en projekt-iteration. Dvs man genomför samma projekt i många iterationer, tills det är tillräckligt bra. Första iterationen så har man gjort projektet (krav, test, utveckling, integration, leveransfärdigt) fast det kanske inte är tillräckligt bra – än, så man gör en iteration till över samma projekt så blir resultatet bättre.

Jag har inte sett många Scrum-projekt som sett på sprintar på det sättet. Även om tanken var att en sprint – skulle vara en iteration av ett projekt.

Sprint och iteration är alltså (oftast) två helt olika saker.

Du kan bygga en funktion under en sprint, och sen strunta i att bygga/förbättra den igen. Då har du inte itererat över den funktionen. Du har bara jobbat i en time-box, en sprint.

Inkrementell

”An increment is an increase of some amount, either fixed or variable. For example one’s salary may have a fixed annual increment of x%” (redigerat från wikipedia).   Om din lön ökar med en fast % varje år, så ökar den i inkrement.

Inkrement är alltså en utökning.

Jag tänker på en bakelse. Säg att du har en liten rund bit sockerkaka och fyller den med bär. Sedan tittar du på den och tycker den förtjänar lite grädde runtom. Du lägger till grädde. Det är ett inkrement. Bakelsen var redan klar att äta och njuta av med sockerkakan och bär, men med inkrementet grädde så har du utökat bakelsen till en lite större upplevelse. Sedan tittar du på bakelsen igen och bestämmer dig för att lägga på riven choklad runtom. Ytterligare en utökning, ett inkrement. Den var redan färdig som den var, men chokladen gav det lilla extra.  Som ett sista inkrement lägger du på hyvlad mandel.

Du hade en färdig bakelse från början med sockerkaka & bär. Bara sockerkakan hade  inte varit tillräckligt, det hade bara varit en sockerkaka. Efter den första inkrementet, utökade du den stegvis, inkrementellt, till en större finare bakelse.

Samma gäller funktioner i systemutveckling. Du bygger en funktion som är färdig som den är. Den går att använda. Sedan utökar du den med (små) inkrement, ett extra värde, ett extra inmatningsfält, extra information.

Exempel
Ett exempel på inkrementell funktionsutveckling var när vi skulle presentera kursinformation i ett utbildningssystem för studenter.

Det första inkrementet bestod bara i att visa upp kurskoden och namnet på kursen. Fullt fungerande.
Det andra inkrementet bestod i att visa upp ytterligare information, såsom kort beskrivning, hur många poäng kursen var, vilken institution som gav kursen.
Tredje inkrementet var att visa upp kurstiteln på engelska och vilka prov som ingick.
Etc.

Vid första inkrementet kunde vi inte släppa funktionen till studenter, den var för fattig på information. Däremot kunde vi visa upp den för vår beställare/kravställare/produktägare, så att han kunde se att det fungerar.
Efter 3:e inkrementet var funktionen redo att släppas till studenter – slutanvändaren.

Skillnaden mellan iteration och inkrement??

Inte helt lätt att avgöra. När man stegvis utökar (increment) – en färdig funktion, så gör man det genom att iterera – alltså återkomma till samma funktion (bakelse) flera gånger.

Inkrement = utökning
Iteration = upprepning

Solklart?

Skulle vara jätteintressant  om den som rättar era tentor vill kommentera den här artikeln, kanske har hen ett ännu bättre svar på skillnaden mellan iteration & inkrement?

Kram

Ulrika





”För att det är tradition…”

25 12 2012

Jag har alltid blivit så oerhört provocerad av detta påstående. Varför har vi julskinka på bordet? ”För det är tradition”, har jag mer än en gång hört genom åren.

Varför inte bara svara ”För att det är gott”, ”För att det ser fint ut”, ”För att det är roligt att griljera” eller någon annan, vilken som helst orsak.

Jag blir så oerhört provocerad av  kommentaren”För att det är tradition…” – oavsett om det gäller julskinka, åka till släkten, köpa julklappar eller något helt annat som inte alls har att göra med julen.

Det som gör mig så provocerad är att svaret är så.. hjärndött. Så total brist på reflektion, vilja, engagemang, tanke. Brist på respekt för sin egen och andras fattningsförmåga. Den mer eller mindre bildade person som gör något, och hävdar traditionen som orsak är inte ett uns bättre än alla dessa som genom historien, och fortfarande, hänvisar till ”att Bibeln säger så” för att förklara sina handlingar, åsikter eller yttranden.

Med argumentet ”att det står i Biblen” eller ”det är tradition” eller ”vi har alltid gjort så” kan man bortförklara de mest vidriga, eller bara korkade beteenden.

Jag tror att det som gör mig så provocerad är att jag vet att ingen häromkring är så oförstående att hen inte kan hitta en annan anledning till julskinkan än just traditionen. Och att jag ser personer göra saker som de verkligen inte gillar ”för att det är tradition”, särskilt runt jul. Orsaken ”för jag försöker lära mig en ny kultur” eller ”jag vill verkligen göra faster Stina glad och åka 100 mil i snöstorm med 4 snoriga ungar” är ju helt förståeliga och antagligen genomtänkta. ”För att det är tradition..” är det inte.

Att ha julskinka på bordet för att det är tradition, utan att ens kanske gilla det, är en dumhet som ingen behöver göra.  Om orsaken är ”för att faster Stina gillar det” är det ju en helt annan grej, självklart ska faster Stina få julskinka. Bra orsak!  Men ”för att det är tradition… ” tar på något sätt bort all intelligens hos personen som säger det.

Ungefär som att vi i säkert 10 års tid efter att någon person sa att det var konstigt att kalla ”chokladbollar” för ”negerbollar” hörde alldeles för många personer, även i film, som hävdade att ”vadå, vi har ju alltid kallat det så”. Samma totala brist på tanke, av människor som faktiskt gått i skolan.  ”Ja, men då så, då fortsätter vi kalla det för det då… ”

”I Bibeln står att homosexualitet är fel”. ”Möjligtvis, men tycker verkligen alla som tror på Gud det på riktigt..?”

Provocerande när hyfsat bildat folk inte använder sin tankeförmåga.

I kontorssammanhang kan man höra samma tema. ”Varför måste du fråga chefen om du får göra den här förstudien som DU anser rätt?” ”För att vi har alltid gjort på det här sättet”.

Kan du förklara varför?

Nu tror jag naturligtvis inte att de som läser denna text skulle få för sig att referera till Bibeln som orsak till dumma uppfattningar eller beteenden, eller ens ”det brukar vara så”. Säkerligen har du dock mer än en gång hört orsaksbeskrivning på jobbet vara ”för att det brukar va så”. Och i privata sammanhang hört annars kloka starka individer som gör märkliga saker runt julen ”för att det är tradition”.

Jag tror att när vi hör ”traditionen” eller ”det har alltid varit så” som argument till att göra saker man inte vill på jobbet eller på julen, så kan vi ändra detta genom att bara uppmnuntra den personen till att förklara sig. ”Ja, men hur skulle DU nu vilja göra?” ”Vad hindrar dig..” och inte nöja dig med ”traditionen” som svar.

En annan tradition som provocerar mig att hänvisa till är ”traditionell projektledning” eller ”traditionella projektverktyg”. Vadå traditionella? Provokationen består i att genom att hänvisa till traditionen så utesluts jag och alla andra som verkar idag från att bidra med kunskap. Även tankeförmågan hos den som yttrar ”att traditionellt har vi gjort så” utesluts. Om samma person i stället berättar vad som är bra med en viss metod eller modell, kommer vi andra säkert förstå och komma med på tåget.

Genom att hänvisa till traditionen anses man inte behöva förklara sig.

Traditionen har inget egenvärde. Punkt. Däremot kan vanor, sysselsättningar, metoder eller modeller ha ett stort värde oavsett hur gamla eller nya de är. Traditionen har inget med ålder att göra.

Brist på reflektion är brist på respekt för sig själv och sin omgivning. Och få saker är så skadligt för mänskligheten som brist på respekt, visst?

Vad vill DU göra under julhelgen? Och vad vill DU göra när du kommer tillbaka till jobbet?

God Föränderlig Jul och Nytt kunskapsutvecklande År!





Att vara projektledare

27 08 2012

Jag fick idag en fråga ”kan du berätta lite vad du gjort som projektledare?” av en person som fått ett erbjudande att prova-på att byta roll.

Jag fick tänka till lite, vad är det egentligen jag gjort i projektledar- och projektledarliknande roller (som t.ex produktägare, scrummaster) under de ca 10 år som jag verkat i rollen.

Jag måste vara ärlig och svarade så här:

I korthet har det mesta jobbet som projektledare handlat om det sociala – att bli kompis med alla – och då menar jag alla, inklusive den där jobbiga otrevliga typen som jag kanske inte alls alltid haft lust att bli kompis med.

Och dessutom få dessa alla att bli kompis med varandra. Som en jäkla kamratstödjare för vuxna helt enkelt. 😉

Andra halvan har handlat om att om att övertyga ledningsgrupper och chefer om att tro på vårt projekt och ge oss de medel (miljoner ibland, lokaler, utrustning etc) till just vårt projekt som vi behöver. Som en jäkla politiker och försäljare helt enkelt. 😉

Och det värsta är att det är sant.

Planering och organisation är typ 1% av jobbet som projektledare.

Vilket när man läser kursprogram och annat kan låta som att det är de 1%-en som det handlar om att vara projektledare.

Vi pratade om detta och jag kom på att ingen talade om detta för mig när jag gav mig in på banan.

Jag kunde också lägga till att, jo som projektledare är man den som får ta smällarna och all skit när saker går dåligt, och när det går bra är det teamet som får beröm. Det är du som står där när det stormar, det är du som får vara försvararsadvokaten när det är svårt och det är dig de hotar att halshugga när det krisar.

”Låter inte så lockande” säger hon.

Om någon sagt detta för 10 år sedan, hade jag ändå tackat ja till det erbjudande jag då fick?

Jag vet inte.

Det tog mig 5 år att börja tycka det var roligt på riktigt att vara projektledare – eller då blev jag ScrumMaster – kanske hade något samband? Eller var det bara så att det var då jag började få tillräcklig erfarenhet för att börja bli bekväm med rollen?

Det tog mig ytterligare 5 år att ha tagit mig igenom strider, stått i blåsten, blivit hotad, kramad, peppad och stressad innan jag började förstå vad teamledarrollen egentligen handlar om. Jag påstår inte att jag bemästrar den, mycket är kvar att lära. Numera är det väldigt roligt och spännande att gå till jobbet och faca de där herrarna i höga hattar som har miljonerna, eller se sitt team växa och nå framgångar.

Det har tagit tid, och jag vet inte om någon annan projektledare skulle säga annorlunda?

Jag har sett så många pressade, stressade, överarbetade, ledsna och oförstådda projektledare runt om.

Samtidigt verkar vi vara ett ordentligt gäng som bara inte kan hålla oss ifrån den här organisation/metod/team/coachande rollen, som bara måste se om det går att komma i mål den här gången och hur roligt man faktiskt kan ha på vägen. Att få möta team efter team av fantastiska människor som älskar att utveckla system, produkter och tjänster i någon form.

Jag skulle inte vilja vara utan det.

Skulle du?





Tips till konsultköpare

18 08 2012

Samma dag jag bestämde mig för att lämna konsulttillvaron ett tag så fick jag några nya insikter, kanske har det med perspektivet att göra. Så snart du kommer utanför det snurrande hjulet är det lättare att observera vad som händer i hjulet.

Något som för mig nu framstår väldigt tydligt är hur extremt mycket (arbets)tid som läggs i vårt IT-samhälle på rekrytering, eller snarare inköp, av tillfälliga konsulter. Både av konsultköpare (ofta verksamhets- eller IT-chefer), konsulterna själva (ofta högavlönade kunskapsarbetare) och konsultsäljare (ofta mycket kompetenta och högavlönade kunskapsarbetare).

Konsulting är den nya anställningsformen. Vad jag ser på svenska IT-relaterade avdelningar är att det inte är ovanligt med hälften anställda, hälften konsulter. Egentligen är det bra, en flexibel arbetskraft som kan röra på sig snabbt när det behövs.

Det som INTE är bra enligt min uppfattning är den enorma mängd tid som läggs på avancerade inköpsprocesser av ett stort antal människor för att ofta inte köpa alls, eller efter en lång och tidskrävande köpprocess, göra ett köp för mycket kort tid t.ex 3 månader.

Jag uppskattar mina tidigare kunder och potentiella kunder, de har varit ambitiösa och ärligt intresserade personer, som gör ett bra jobb. Det jag kritiserar nu är systemet för hur svenska organisationer ofta upphandlar konsulter. Av gammal vana, tradition eller bara en viss brist på analys av processen.

Det är inte sällan jag varit med om 3 månaders inköpsprocedur för ett 3 månaders konsultuppdrag. Samtal, intervjuer, mail, telefonkonferenser, cv-skrivande, prov-seminarier, uppföljning, intervjuer och lunchande med ännu fler (annars väldigt upptagna) chefer.

När jag slog ihop det totala antalet arbetstimmar som lagts ner av ett företag för mitt eventuella 3-6 månadersuppdrag, av ett 10-tal chefer + min egen och säljarens tid, fick jag ihop det till minst 40 timmar, en arbetsvecka av högkvalificerad arbetskraft.

Tänk hur många samtidiga köpprocesser som pågår just nu, även om det bara vore 10 samtidigt = 10*40 = 400 arbetstimmar som tas från något annat – mer värdeskapande arbete i våra organisationer?

Är det värt det?  

När beställaren efter några veckor kommit fram till att ”jo, det verkar bra vi kör på detta” och hörde av sig till säljaren för att göra upp, hade konsulten naturligtvis hunnit tacka ja till ett annat uppdrag. Och beställaren fick börja om processen med den 3:e potentiella konsulten. Hela köpprocessen var vid detta tillfälle uppe i ca 4 månaders kalendertid, eftersom en tidigare tillfrågad konsult också hunnit tacka ja till något annat medan beställaren konfererade.  Innan de hittat nästa potentiella konsult har kalendertiden överstigit tiden för uppdraget.

Är detta klokt??

Och jag har sett samma sak, gång på gång på gång.

En annan lika vanlig variant är:

Beställaren kontaktar oss (konsultföretaget) av personliga skäl, känner någon som rekommenderat någon etc. Vi åker dit med den rekommenderade personen, för en både lång resa och lång intervju där konsulten presenteras för olika personer, introduceras till beställarens organisation och utmaningar, en dialog startar och fortsätter på mail och telefon efter intervjun.

I detta fall är beställaren ganska snabb på att bestämma sig för att ”jo, det här verkar bra, vi vill gärna jobba med dig.” ”Så nu börjar vår budgetprocess. Vi hör av oss när den är klar”.  !!  Det fanns inte ens avsatt medel för att göra ett inköp!!  När budgetprocessen sedemera är klar och det verkar finnas ett ok på finansiering, ca 2 månader senare, är naturligtvis konsulten ute på annat uppdrag och kan inte tacka ja. Så beställaren, konsultköparen, får börja om köpprocessen. Denna gång förhoppningsvis med budgeten klar.

I detta fall, när jag lägger ihop timmarna, är vi ca 5 inblandade personer i köpprocessen, hos beställaren och hos leverantören. Högkvalificerade kunskapsarbetare som tillsammans lagt minst 30 arbetstimmar på en inköpsrutin som inte ens kunde leda till något, eftersom budgeten inte var säkrad.

Är det värt det?

Vad tycker du som konsultköpare? Kanske är det någon viktig del jag missat, som jag inte förstår.

Jag tror att hela denna procedur handlar om att köparen så gärna vill göra rätt. Det ÄR mycket pengar för de flesta att köpa en kosult för kanske 1000 kr/tim och uppåt. Därför vill köparen göra allt som står i dennes makt för att säkerställa att det är rätt person, rätt kompetens som kommer in. Så köparen ser till att skaffa förankring, genom att flera viktiga personer involveras, att det avsätts ordentligt med tid för intervjuer, presentationer och uppföljning. Kanske ett prov-uppdrag (seminarie-liknande aktiviteter som den tänkta konsulten förväntas hålla) etc. För om alla dessa undersökningar gjorts kommer rätt beslut fattas.

Viljan att göra rätt verkar ha en förmåga att gå överstyr.

Både hos köpare, konsulter och säljare.

Och när köpprocessen är klar, är konsulten redan upptagen på annan plats och oändligt många arbetstimmar har lagts på en köpprocess som inte leder någonstans.

Så här skulle konsultköpare kunna göra i stället, åtminstone vill jag agera så när jag står i köpläge:

  • Pengarna först! Money talks! Se till att du som beställare har en avsatt budget redan när du börjar, så att när du hittar rätt konsult kan slå till direkt utan väntan.
  • Genom detta kan förankringsprocessen handla om avsatta medel, snarare än person. Så när det är dags för personintervju – kan du sköta det själv med någon nära teammedlem.
  • Får du ett bra intryck av personen och hyfsat pålitliga meriter,  ge det en chans, med möjlighet till snabb utgång. Avtala fram snabbt inköp – snabbt avslut om personen visar sig vara fel. Våga riskera att du omöjligt kan ta reda på allt om personen i förhand. Väg tiden före mot värdet efter.
  • Om personen är rekommenderad av någon du litar på, eller du har hittat denna genom dina nätverk och kontakter, slå till direkt! Det kan visa sig vara fel, men vad är rekommendationer annars värt?
  • Bestäm i förhand hur mycket tid som får läggas totalt på köpprocessen av involverade personer internt. Fördela den där det ger mest värde. När den bestämda tiden är förbrukad, fatta ett beslut. Är du för osäker? Fatta beslutet nej då.

Konsulter är en fantastisk kraft för tillfälligt arbete, när du inte vill anställa. En mer medveten köpprocess kommer gagna både köparens organisation och samhället genom att kompetens används där den gör mest nytta.