As a buyer of a new system we formalize our expectations on the solution we want with functional and non-functional requirements. We also make sure that the new vendor is compliant with all our standards and values and that they have good credit rating and great references. And of course the price as an offer you cant refuse offered by a very nice salesperson. But what about the relationship between the two soon-to be-partners? I have been working with procurement for both sides - the vendor and the buyer - and both take for granted the upcoming collaboration will be smooth. It is often not and soon the blame game is on. So why don’t we set the expectations on eachother ways of working as partners, instead of vendor/buyer, early in the RFI so we mitigate the risk of project failure?

För mig är det en stark drivkraft att förstå hur min insats har påverkat ett initiativ, såväl utifrån projektets framdrift som den slutliga lösningen. Med det som utgångspunkt försöker jag se hur jag kan förbättra mitt sätt att arbeta som kravanalytiker. 

Tobbe: Jag vill ha en syltbulle!

Robban: Va?

Tobbe: Jag vill ha en SYLTbulle!

Robban: Är du hungrig??

Tobbe: Mmmm... kan inte du SNÄLLA gå och köpa en på Fabrique? Jag swishar!

Foto av Staff Sgt. Michael Battles

Nyligen hjälpte jag en startup med kravhantering. Det gick inget vidare då chefen ändå smög in brådskande nya features på post-it lappar och jag kunde inte förstå varför teamet jobbade sena kvällar.

Före det hjälpte jag ett 100 årigt gediget svenskt tjänsteföretag med att, bland annat, coacha produktägarna. Det gick heller inget vidare då produktägarna inte hade tid och behövde sköta sitt riktiga jobb.

Så vad förenar dessa två helt olika organisationer om vi håller oss till krav? Jo, bägge företagen fuskade grovt med flera rubricerade dimensioner av krav (och en hel del annat) och här är min spaning hur dessa kan skapa ett fundament för bra krav. (Givetvis har jag feedbackat detta till respektive företag men det tål att tas upp igen.)

På pappret är produktägarskapet väldigt enkelt – maximera affärsvärdet av ett teams arbete. VAD ska göras och NÄR. I verkligheten är detta inte fullt lika trivialt. Även om man föresatt sig att jobba agilt så finns det ofta faktorer som stör en strikt prioritering helt efter affärsvärde – beroenden till andra team, kunskaper hos olika teammedlemmar med mera. Jag skulle vilja dela med mig av är några tips kring hur man kan agera som produktägare.

På Kravdagen 2019 kommer vi under programpunkten Speakers Corner att bjuda in till tre olika diskussioner om Roller, Metoder och Krav. På temat "Vad kan man kräva av Krav?" kommer jag att tillsammans med dig och andra kravintresserade att diskutera olika infallsvinklar och uppfattningar kring begreppet Krav.

Något jag tycker mig se som ett återkommande mönster i många av de IT-projekt jag arbetar som kravare i, är vilken extrem tilltro vi tillskriver metoden. Använder vi oss bara av de vedertagna och framförallt moderna metoderna så kan det ju inte gå fel. Men används metoderna för att gynna vårt sätt att arbeta och ta beslut på eller för att det helt enkelt ”är så man gör”? Klart vi inte skulle erkänna att vi bara följer strömmen, men ibland får jag känslan av att vi ändå är rätt dåliga på att utvärdera det arbetssätt vi använder. Några exempel nedan.

Bilden ovan är målningen De Kwakzalver gjord av Jan Steen.  Bilden är fri för användning på Wikimedia commons

Den frågan ställer jag mig då det är tre roller som jag har verkat inom men som jag nu märker blivit överflödiga, och därmed också jag, likt maskinskriverskor, rallare och kvacksalvare*? Jag har väl 10 år kvar i branschen, men kan jag hänga kvar alla dessa år när yngre hungriga talanger, med coolare och kryptiska titlar som tex RTE och med certifikat som utklassar mitt CV. Och efter något år i rollen lägger de till prefixet senior och dubblar sin lön. Och nu ska de nu höja pensionsåldern till råga på allt. Brandmän och balettdansörer får ju gå innan 60 så vore det inte på plats att överflödiga IT-konsulter som jag får göra det också?

"Tre blinda män skall tillsammans köpa ett dragdjur och blir presenterade för en tapir.

Den förste tar på snabeln, den andre klappar på sidan och den tredje tar tag i svansen.

Efter en kort diskussion konstaterar de gemensamt att djuret de mött måste vara en elefant. De bestämmer sig för att djuret uppfyller deras krav och de slår till på ett köp då de får den till ett vad de tycker är ett bra pris.

När djuret senare levereras inser männen att elefanten de köpt är en tapir vilket såklart inte alls motsvarade deras behov."

Alla har vi varit där. På konferenser och på kurser, på teambuildingaktiviteter och kick-off. Nu ska vi äntligen få lära oss en ny och användbar metod från branschens just nu klarast lysande stjärna. Inte nog med det, vi ska ha kul på kuppen!

Men, hur bra är den enskilda metoden egentligen? Är den rentav skadlig!?

Folksagan om Mäster Skräddare är ett underbart exempel på hur en beställning inte ska beställas, hur ett projekt inte ska genomföras och hur en leverans inte ska levereras – med andra ord hur en verksamhet inte ska bedrivas hur och en kundrelation inte ska hanteras.

Rubriken skulle också kunna vara ”Är Produktägaren vår Superhjälte?” eftersom produktägaren såsom jag känner rollen måste vara en mångkonstnär av rang samtidigt som produktägandet ska kombineras med andra åtaganden. Låt gärna bilden av Superhjälten vila i minnet medan du funderar på hur många Superhjältar du mött så kan vi återkomma till den bilden lite senare.

En sak som jag har funderat över är att det är så effektivt att jobba fram krav och lösning tillsammans i grupp med olika discipliner representerade och att arbetssättet ändå så ofta ifrågasätts. Mycket av ifrågasättandet handlar om att det tar mycket tid från många resurser. ”Behöver ni verkligen sitta tillsammans hela tiden” och ”kan ni inte dela upp jobbet”.

The Swedish academy is the governor of the Swedish language but when you search for the word agile in their online dictionaries you get no hits. I heard it takes twenty years for a new word to get added. Not so agile.

But if you search for the word resource you get hits explaining the meaning as opportunity or way out, often in the context of financial assets. This post is about the words that we can stop using and which to start use instead, so we understand each other better, for instance, the awful word resource.

GDPR, eller The EU General Data Protection Regulation, som den också kallas för. Den har ni inte missat, va? Om ni tror det handlar om en ny viktminskningsmetod så här inför sommaren, så kan det vara dags att börja googla efter ”GDPR” och se vad det egentligen handlar om. Men, du får vara lite kvick nu, för den 25/5 börjar den gälla. För alla företag, stor som pytteliten.

Vad kan vi lära oss från matlagning? Precis som vid kravhantering och programutveckling kan man tillämpa olika tekniker och ”best practices”.

På de flesta företag finns processer för hur kravarbetet ska utföras. Vad som ska göras, när och på vilket sätt. Ofta används en agil approach och ibland kombineras det med en projektstyrningsmodell. Som ”kravare” har man också ofta flera arbetssätt i sin verktygslåda. Allt från det klassiska upplägget med Elicitation, Analysis, Specification och Validation, till User Stories, Use Cases 2.0 och Volere. Det finns med andra ord gott om arbetssätt och metoder beskrivna, och som kravare vet man vad som är viktigt för att resultatet ska bli bra.

Det var bara det där med verkligheten.

Nudging är ju hett i dessa Nobel-dagar. Börjar man läsa om det yttrar det sig i många olika former och situationer. Nudging är en gren inom beteendeekonomi som handlar om hur man kan påverka människors beteende genom att arrangera en valsituation. Och vi som är verksamhets- och  kravanalytiker är inte undantagna enligt mig.

Sällan är vår enda uppgift att bara dokumenterar ner vad andra tycker och tänker. Ofta handlar det också att på ett pedagogiskt sätt presentera argument till olika beslut; det kan vara allt från ett business case, en plan, alternativa lösningsförslag, mockuper, etc.

Oavsett så finns det definitivt en dos av nudging. För beroende på hur vi presenterar det vi vill få fram så kommer mottagaren skapa sig en uppfattning baserat på just formatet och dispositionen. Det är viktigt för oss att vara medvetna om detta beteende då vår roll ibland ska vara neutral och ibland vill vi rikta vårt budskap i en given riktning.

Har du någon gång lyssnat på en riktigt inspirerande presentation på jobbet? Sannolikheten är tyvärr inte så stor. På en arbetsplats hålls många presentationer, men de flesta är ganska ordinära. Hur brukar du tänka och känna efter att ha varit på en presentation? Antagligen är du trött. Entusiasm? Nja…

Varför ser det ut så här? Det blir helt enkelt inte prioriterat. Framförallt tror väldigt många att det inte är så viktigt med bra och intressanta presentationer. Det räcker väl med att skriva ner det som ska sägas i PowerPoint och sedan säga det? Varför lägga extra tid på något sådant?

Känslan som lätt uppstår under en långdragen och tråkig presentation.

Under min första sommar med min blivande fru så skulle jag imponera med att fixa midsommarmiddagen. Hon skulle komma över till mig efter jobbet runt klockan 15 och sedan skulle vi ut på stan. Jag hade fixat sill och alla tillbehör och dukat upp ett magnifikt sillbord med olika sorter både på sill och nubbe. Efter första nubben undrade jag varför det inte smakade? Du gillar väl sill? Och nubbe? Jodå, det var helt OK men sen berättade hon att hon hoppat över lunchen och hade sett fram emot någon biff eller pasta. På midsommarafton, allvar!? Gungan i bilden ovan här var ordet "midsommarmiddag" som vi tolkade på olika sätt.  Då insåg jag värdet av att prata så att man förstår och sedan dess berättar jag för henne alla ingredienser i maten innan jag tillagar den.

”Beskriv dina behov och inte en lösning! Det är vi som ska komma på lösningen” är något som man kan höra rätt ofta från en frustrerad kravhanterare eller systemarkitekt.

Det finns nog ett par olika anledningar till att man enkelt hamnar i den situationen när IT och verksamhet diskuterar framtida initiativ. En är att det oftast är enklare att uttrycka sina behov via en lösning eftersom man också har idéer på hur lösningen ska se ut. Att sedan öppna upp för en annan lösning än den man sett framför sig kan både kännas riskfyllt, skrämmande, och framförallt blir ju lösningen då någon annans.  Detta skapar ofta ganska mycket friktion. Att envist basunera ut att man ska hålla sig borta från lösningen är kanske inte de pedagogiska knepet att ta till i dessa lägen och det är heller inte helt rätt (enligt mig).

Jag hade möjlighet att besöka Almedalsveckan för några veckor sedan och fokuserade lite på seminarier som handlade om upphandling i olika former. Klart intressanta och välbesökta!

Medan jag ömsom lyssnade och ömsom la mig i debatten lite grann, så reflekterade jag lite och nu undrar jag såklart om det finns någon som sysslar med upphandling i någon form som läser detta och håller med / inte håller med om mina spaningar?

Har du barn? Eller har du varit ett barn? Eller du kanske fortfarande är ett barn?

Någon av dessa frågor bör du ha svarat ”ja” på och då har du kvalificerat dig för att läsa vidare i texten nedanför. Om du svarade ”ja” på alla tre frågorna, så har du allra störst förutsättningar för att snart kunna glänsa på jobbet nästa du gång du ställs inför ett knivigt problem.

Det är inte bara sommarens efterlängtade semester som snart kör igång – det gör även pendeltågen på den nya Citybanan i Stockholm. Det är med spänning vi väntar på att se hur rätt det blev. Kommer stationerna ha "god orienterbarhet" och "gångvägar ska kännas naturliga" och har man lyckats "undvika prång och dolda hörn"? Och kommer dörrarna på plattformen att öppnas när tågets dörrar öppnas, och sen stängas när de ska? Det är en riktig nagelbitare för många.

Så var den utmanande rubriken vi, ett antal förespråkare av agila processer, ställde för tio år sedan på vår inbjudan till paneldebatt på temat. Undertiteln var Rallare, kittelflickare och maskinskriverskor och nu projektledare. Lokalen var till 90% fylld av oroliga, uppretade eller bara nyfikna projektledare och de resterande var vi fem som arrangerade. Då var vi fortfarande lite blöta bakom öronen när det gällde agilitet, som då var något katten hade släpat in i källaren medan den övriga organisationen fortsatte göra som de alltid hade gjort. Kvällen slutade i alla fall med hyfsad enighet om att rollen som sådan var på väg att förändras till förmån för mer självgående strukturer. Jag vill minnas att sista ordet den kvällen var att det alltid kommer behövas dagisfröknar.

Så vad hände sen?

Har ni hört talas om "filterbubblan" när det kommer till sociala medier och sökningar på internet? Kort sammanfattat kan man säga att det som presenteras i form av sökresultat och nyhetsflöde numera alltid har filtrerats och personifierats utefter dina (outtalade) preferenser. På det personliga planet har vi motsvarande mekanismer, där hjärnan kortsluter och försöker hitta enkla sammanhang som styrker redan tillskansad kunskap.

För några år sedan sa en kollega till mig att "en expert som bara förlitar sig på sin expertis, förlorar i det långa loppet mot en novis som drar nytta av sin omgivning".

Jag har burit med mig detta och försökt att omvandla det till ett förhållningssätt rörande både min och andras kunskap - även när man tror att man vet allt så gör man inte det.

Det går inte att fråga en användare vad hen vill ha när det kommer till IT stöd för verksamhetsprocesser.

Varför inte?

• Ofta får man inte de stora penseldragen och de mer strategiska perspektiven från en slutanvändare. Det blir lätt att man cementerar dagens sätt att arbeta då man har svårt att lyfta blicken.
• Det kan lätt bli lite för mycket "läppstift på grisen" alternativt att man suboptimerar outputen utefter specifika behoven. Man tar helt enkelt inte in helheten i beräkningen när man tittar på var man ska lägga sitt krut. Vad är affärsvärdet för att implementera en viss feature kontra en annan?
• En slutanvändare kan också ha svårt att artikulera vad det är man vill ha. För att ta ett klassiskt T-Ford exempel: Om du hade frågat vad folk ville ha så hade de sagt "snabbare hästar", när deras egentliga behov var snabbare transporter.

Självklart menar jag inte att man ska stänga ute slutanvändaren, men ibland blir jag lite provocerad av bilden att de sitter på hela sanningen. De ska vara med och forma lösningen men på ett balanserat sätt.

Så vilka kompetenser behöver vara med för att vi ska göra rätt saker och få ut rätt output?

Det finns två uppgifter som man som kravanalytiker måste förhålla sig till. Den första är det dagliga arbetet med att ta fram krav på de behovsställningar som finns i verksamheten. Den andra är att sätta formerna för hur kravarbetet skall bedrivas. Den senare är en förutsättning för att den första skall kunna göras så effektivt som möjligt och till ett bra resultat.

Hur man arbetar med krav skiljer sig från verksamhet till verksamhet beroende på förutsättningarna som ges. Fler känner förmodligen till rollen kravanalytiker än de som fullt ut förstår hur man arbetar och vilka förutsättningar som krävs för att kunna leverera en bra och fullständig kravställning. Hur man kommer att kunna arbeta i rollen beror därför mycket på sammanhanget man hamnar i. Mognad och erfarenhet av att arbeta med förändring i en verksamhet samt övriga rollers uppdrag och ansvar är några avgörande för faktorer.

Oavsett utgångspunkt är det många roller som behöver involveras i kravarbetet och som behöver få en förståelse för vad de ska bidra med och på vilket sätt. Men det gäller även att skapa utrymme för de aktiviteter som från ett kravperspektiv behöver genomföras i initiativet.  Att reflektera och planera för dessa två är viktigt för att kunna skapa förutsättningarna för ett bra kravarbete.

Det är alltid en utmaning som kravanalytiker att säkra att man fångar alla aspekter nödvändiga för den lösning som skall tas fram eller att inte förlora momentum i kravarbetet.

Elicitering, eller kravinhämtning som det också heter, handlar just om den del av kravarbetet som syftar till att få fram olika intressenters krav, väga dessa gentemot varandra, för att till sist kunna presentera en sammanhållande kravbild. Den som arbetar med krav har dock många gånger fått erfara att de involverade kan ha skilda uppfattningar kring det område i verksamheten som är föremål för en förändring.

Det är också viktigt att som kravanalytiker hålla engagemanget uppe bland de som deltar i kravarbetet. Haltar de inledande diskussionerna och tiden drar ut utan att man lyckas uppnå något resultat, riskerar man att förlora intresse och fokus bland dem man är beroende av.

Att skapa en samsyn är därför A-O för att få igång arbetet på ett smidigt och smärtfritt sätt. Processer är då ett bra sätt att skapa en gemensam bild av verksamheten utifrån vilken kommande diskussioner kan ta sin utgångspunkt.

Under en av våra AWs på Require pratade Tobias Nilsson om möten och problemen med att få folk att gå på dem. Han lekte då med titeln på anförandet "Ingen kommer på mina möten" som med en bokstavsändring blev "Ingen kommer på sina möten".

Inför arbetet med Kravdagen 2017 satt jag och bollade uppslag till tal med en av anförarna och fick följande förslag "Att ställa krav är att bry sig".

Båda dessa uppslag pekar på något man ganska ofta hamnar i som kravhanterare, verksamhetsanalytiker, eller processledare - folk tror att man jobbar efter egen agenda. När man i själva fallet jobbar för någon annan och där denna någon i många fall är den som ska ställa kraven och komma på möten.

Det händer lite nu och då att någon lägger upp en bild på Linkedin med ett citat av Oren Harari som säger ”The electric light did not come from continuous improvement of candles”. Det ska tydligen vara något sorts statement mot agila metoder och specifikt då Continuous Delivery antar jag. Det blir en hel del delningar och ”Spot on”-kommentarer varje gång den dyker upp. Själv blir jag lika förvånad varje gång, både att folk delar ”tänkvärda citat” på Linkedin men också att folk håller med när citatet ju faktiskt missar målet fullständigt.

Arbetet med att ta fram en lösning på ett behov eller problem involverar ofta många personer, alla med olika ansvarsområden, kompetenser och uppgifter. I en processorienterad verksamhet samverkar dessa för att uppnå ett resultat, där var och en bidrar med sin del utifrån hur behov, krav och lösning ser ut.

Likväl talar vi ofta när det kommer till krav om överlämning av dessa mellan olika roller i initiativet. Detta är något som skapar ett problem eftersom det i begreppet överlämning lätt tolkas, medvetet eller omedvetet, som att man överlåter ansvaret för dessa till någon annan. Risken blir att man som kravansvarig tar ett steg tillbaka och väntar på att en lösning skall presenteras eller få ett kvitto på att beställaren är nöjd. Inget kan vara mer fel!

Igår hade jag möjligheten att prata på Requires After Work. Jag berättade om likheter och olikheter som jag har upplevt efter att ha jobbat med krav i över 15 år inom olika branscher.

Den mest slående likheten tycker jag är att det ALLTID är BRÅTTOM.

Som konsult ligger det lite i sakens natur att det är bråttom eftersom man tar in konsulter när man saknar tid eller kompetens att göra något själv, men att det är bråttom gäller inte bara när jag arbetat som konsult. Ofta är det också brist på förståelse för "VARFÖR TAR DET SÅ LÅNG TID". 

Har precis läst ut boken ”Lean from the Trenches” av Henrik Kniberg. En lättläst bok om hur de jobbade i ett stort projekt med 60 projektmedlemmar på Rikspolisstyrelsen.

Henrik beskriver hur de kombinerade XP, Scrum och Kanban. Boken tar upp vad som fungerade, vad som inte gjorde det, varför och hur processen utvecklades.

Det beskrivs hur de arbetade praktiskt genom hela utvecklingsprocessen. Jag tycker boken blir levande genom verkliga exempel och massor av  foton på t.ex. deras fysiska Agila tavlor.

Jag blir så glad över att läsa om ett projekt där man tillsammans arbetar fram ett sätt att jobba effektivt ihop. Hur man gör stora förändringar genom att låta små förändringar i samma riktning ske ofta.

Samtidigt funderar jag på om hur det känts om jag hade varit med i projektet. Henrik var inne i projektet ett halvår och det är det halvåret som boken beskriver. Det måste ha varit mycket stimulerande och intensivt att vara med och förändra projektet tillsammans.

Men vad händer sedan.

När vi pratar om krav och kravarbete kopplar man oftast detta till arbetet med att ta fram en specifikation som skall ligga till grund för en lösning och acceptans av denna. Men det finns ett annat perspektiv som inte alltid får samma fokus men som är av stor betydelse. Nämligen att ta fram ett väl underbyggt beslutsunderlag för att säkra att man arbetar med rätt behov.

Jag menar att för varje behov man arbetar med att förverkliga så finns det tre frågeställningar som behöver besvaras för att just säkerställa detta, nämligen;

• Är behovet relevant?
• Finns det ett business case?
• Efter detaljering, håller Business case:t?

Svaren på frågorna får man fram genom att arbeta iterativt med behovsställningen, dvs genom att bryta ner behovet får vi mer kunskap och insikt och därmed bättre förutsättningar för att både värdera behovet i sig men även sätta det i förhållande till andra. Utgångspunkten är att säkerställa att man hela tiden arbetar med de behov som genererar mest affärsvärde och samtidigt få en förståelse för vad det medför att förverkliga det.

Låt oss titta närmre på var och en av dessa och vad de tillför! 

Vi är Linus Lundahl och Fadi Rabah, två studenter från Nackademin som gör sin LiA period på Require AB. I september gav Require oss den fantastiska möjligheten att delta i Mastering the Requirements Process, en tredagars kurs ledd av Suzanne Robertsson. I det här inlägget presenterar vi våra reflektioner efter kursen.

Volere – italienska för att önska eller vilja. Ett ord Suzanne ofta återkommer till i kursen. Volere är också namnet på ett koncept framtaget av Suzanne och James Robertson som omfattar framtagandet, kommunikationen och hanteringen av krav. För oss är det inte möjligt att helt sammanfatta dessa tre dagar i ett blogginlägg, med tanke på vilket gediget material kursen består av. Alla deltagare tog säkert med sig olika tankar, idéer och verktyg när de gick hem efter kursens slut – men här nedan följer våra tankar och intryck av kursen, och av Volere.

Det finns inget ord som både brukas och missbrukas så mycket i vår bransch just nu som ordet Agile. Alla ska vara agila. Vad det innebär exakt är inte så viktigt, bara vi blir agila. Det är det senaste, det bästa och det löser alla våra problem. Att många företag har svårt med en agil transformation är ett faktum och det kanske inte är så konstigt när man inte tar sig tiden att förstå vad en sådan faktiskt innebär. Man blir inte agil över en natt.

Jag börjar med att sticka ut hakan genom att generalisera rörande hur man är organiserad på större företag:

• Den verkliga beställarsidan på företag är processorienterade, detta medför i det flesta fall att deras IT-stöd består av fler än ett verktyg.
• Många gånger är IT-sidan på företag orienterade efter verktyg, åtminstone när det kommer till verklig implementering och exekvering.

Moderna utvecklingsmetoder förespråkar att man som beställare ska jobba nära implementationsteamet. Detta betyder, tillsammans med ovanstående generalisering, att en beställare kan ha fler än en motpart när det kommer till att realisera sina behov.

De senaste åren har jag jobbat både som kravställare och som kravhanterare. Jag har därmed erfarenhet av både egen och andras frustration kring när produkt/projekt krockar med process.

Då drar vi igång Kravbloggen igen efter semestern och vi börjar med ett gästinlägg av inga mindre än Suzanne och James Robertson. Suzanne kommer till Stockholm och håller kurs den 27-29 september. Se mer här

The User story considered harmful

Ofta när man diskuterar kommunikation så handlar det om hur man ska förmedla något som ”avsändare” av information. Men eftersom kommunikation oftast handlar om en dialog så behöver vi erkänna att vi har två sändare och två mottagare. Det kan var en obalans av aktivitet mellan parterna men det är en dialog även om den ena pratar och den andra bara hummar jakande.

Det finns en term som jag tycker man kan använda sig av för att beskriva detta ”feedbackande” och det är att reflektera. Normal pratar man om att man reflekterar och summerar i samtal, men det är ett koncept som kan användas i mycket mer än samtal. Det belyser en otroligt viktig egenskap i kedjan att realisera ett krav. Det är inte en envägskommunikation som möjliggör att man träffar rätt – att behovet som kommunicerats initialt, faktiskt resulterar i just den ”feature” som faktiskt efterfrågades. Det kräver att man kontinuerligt återkopplar och säkerställer att det man hört faktiskt överensstämmer med det som var tanken hos avsändaren. Vi kan minimera risker genom att minska antalet led och överlämningar, men så länge inte idén föds och implementeras av samma person så behövs feedbackloopen (= reflektion). Det handlar ju inte bara om att bara putta information nedströms. Både avsändare och mottagare vill ha kvitto på förståelse, då information filtreras efter mottagarens hjärna och inte sändarens.

Låt mig presentera ett dilemma som jag då och då brottats med och även hört kollegor/vänner i branschen prata om. Ett dilemma som består av följande komponenter:

• Ett projekt vars huvudsyfte är att ersätta befintlig lösning med en ny. Samma funktionalitet men baserat på ny, modern hårdvara och utvecklat i ett nytt och modernt programmeringsspråk.
• En beställare och styrgrupp som med ett tydligt statement sagt att eftersom det är samma funktionalitet, så behöver vi inte kommunicera i onödan med slutanvändarna. Ingen idé att röra upp damm och skapa oro.

Någon som känner igen sig? Någon som anar i vilken riktning detta blogginlägg är på väg åt?

Svårigheter med LOU och ett förslag på lösning

Till och från skrivs det en del om Lagen om Offentlig Upphandling (LOU) och vad den får för konsekvenser och vilka problem den ställer till med vid upphandlingar. Många av de som debatterar detta är representanter för upphandlande myndigheter av olika slag. Ibland ställs det krav på att förändra lagen så att det ska bli lättare att upphandla så man får det man vill ha.

På ytan så kan det vara ett attraktivt sätt att se på det. Om vi ändrar lagen så att vi får större frihet att välja vad vi vill så blir allting lättare och bättre. Problemet är dock själva anledningen till att vi har LOU över huvud taget, nämligen för att motverka korruption och nepotism. Pengarna som de upphandlande myndigheterna använder är inte deras egna. Det är allas pengar och det är myndigheternas ansvar att använda dem på bästa möjliga sätt.

Visst kan det finnas saker i lagen som kan förenklas men som jag ser det ligger inte problemet i LOU utan i hur man arbetar med den.

Den gängse uppfattningen är att man måste köpa det billigaste alternativet och att man inte kan ta hänsyn till saker som miljö, närproduktion och kvalitet. Men om man läser lagen (ganska ofta får jag känslan att många debattörer inte har gjort det) så är det tydligt att det inte är fallet.

I mitt nuvarande uppdrag som Risk Manager inom ett stort program på ett av de större svenska företagen består min vardag av att, baserat på olika typer av information och kommunikation, försöka se in i framtiden och göra en bedömning av om det finns några risker/hinder/osäkerhet för att man ska lyckas leverera projekten inom programmet. Vad gäller arbetssättet råder det inga som helst tvivel om likheterna mellan jobbet som Kravanalytiker / Business Analyst och mitt uppdrag som Risk Manager. Båda rollerna innebär en hel del faciliterande av olika typer av möten, envist frågande, läsande och bearbetande av en massa information, fler frågor och så även en hel del dokumenterande. Och sedan lite mer frågor. Lite jakt på viktiga personer höll jag på att glömma bort.

Många företag ska eller har redan gått över från vattenfall till agil utveckling och försöker ändra kravanalytikerrollen i deras organisation och anpassa den till agil utveckling. En hel del diskussioner pågår för att bli av med kravanalytikersrollen eller göra rollen mer agil. Men vad är en agil kravanalytiker och bör vi avstå från att ha kravanalytiker i våra organisationer?

Jag tror att alla är överens om att det är viktigt att kvalitetssäkra kravspecifikationer. En felaktig eller inkomplett kravspecifikation kan få katastrofala följder. Som kravansvarig har man gjort sin kravplan och punkten ”kravgranskning” låter ju tämligen enkel att genomföra. Men är det så i verkligheten? I många fall inte tyvärr.

Jag satt nyligen i ett mötesrum fullt av människor med lite olika roller; systemarkitekter, kravledare, produktägare, säkerhetsspecialister, dokumentatörer... Syftet med mötet var att gå igenom ett antal produktinitiativ som hade samlats in för en tid sedan, och att följa upp vårt gemensamma arbete med att bryta ned dessa till mer konkreta features. Utkast till funktionella business-features varvades under diskussionen med arkitekturella features (eller enablers som de nuförtiden kallas enligt SAFe-ramverket som projektet ifråga hämtar inspiration ifrån).

Stämningen i rummet var inte direkt dålig, men jag kände ändå i maggropen att två läger höll på att utkristalliseras.

Jag har tänkt på hur mycket likheter det finns mellan kravhantering och semesterplanering. Vi satt för någon vecka sedan och skulle planera sommarens semesterresa. Vi, en familj med tre barn, är alla primära intressenter med olika behov och önskemål. Vi vill alla ha det varmt och skönt, äta gott, bada och hitta på äventyr, så de övergripande målen är vi enade om. För mig och min man är det viktigt med chans till avslappning och jag tror att barnen har samma behov även om de inte uttrycker det som ett krav.

När man snabbt tittar på dessa övergripande mål så kan man tro att en två veckors charterresa med all-inclusive och lite dagsutflykter skulle passa oss, men det vet jag att vi inte skulle bli trivas med. Där kan man se vikten av att förstå våra riktiga behov och önskemål istället för att direkt gå in på en lösning.

Vi pratar ofta om att några av de största utmaningarna kring produktutveckling och innovation är att inte förlita sig så mycket på gammal kunskap och att lyckas bryta gamla mönster och arbetssätt. ”Vi har alltid gjort så här” är en vanlig kommentar när man ifrågasätter något i ett projekt. ”Vi vet hur man gör, vi har gjort det här i 100 år” är en annan. Det är väldigt svårt att tänka nytt. Igår hos en kund hände dock något som fick mig att reflektera över hur mycket jag själv är fast i olika vanor.

Jag hade i fredags möjligheten att tala på ett frukostseminarium som Require ordnade. Jag berättade om utmaningarna jag stött på från att ha arbetet i såväl förstudiefas som i förvaltning och i skilda branscher såsom läkemedel, telecom, bank och offentlig förvaltning. Utmaningarna har genomgående handlat om kommunikation och samarbete. Min tes är att receptet på att överkomma de allra flesta av dessa utmaningar är att vara agil.

Ett nytt år ligger nästan orört framför oss. Kanske är det lite ute att ge nyårslöften, men någonstans under ytan brukar man ändå uttala lite förhoppningar om det nya året. Vi som arbetar med kravhantering grunnar säkert på hur vi ska kunna bli bättre på att lägga grunden för framgångsrika projekt och ta fram rätt produkter. Inventerar jag mitt 2015 hittar jag ett par riktigt grundläggande ”low hanging fruits” att polera lite på, som kanske du också känner igen…

2016 tänker jag nämligen bli ännu bättre på … att dokumentera motivering och källa till ett krav.