När är det värt mödan att ge sig på en förändring och den resa det ofta innebär?
- Det är när det är din inom "my business”.

När man lagar mat behöver man veta vad det är man vill uppnå, vad som är viktigast och förstå situationen man står inför. På samma sätt är det med jobbet som verksamhetsanalytiker / kravhanterare. 

Sammanhanget som du är i och situationen du står inför måste påverka hur du tar dig an din uppgift. Att använda samma metoder, verktyg och angreppssätt oavsett kontext kommer ge dig, alternativt din uppdragsgivare, huvudvärk. Inget uppdrag är det andra likt och detta behöver man acceptera och anpassa sig efter. 

Robert started this series with Let’s go “all in”! And in that blog post he mentions going all in without questioning, without adapting to your abilities, context or without applying some common sense. 

Common sense is something people often use to value other people’s actions and behaviors. Completely disregarding their own behaviors. Or rather, Common sense for them is a projection onto others as something that should be applied in all situations. As if that would be a miracle cure.

But what is common sense? 

This is the definition of “common sense” according to dictionary.cambridge.org: 

 “The basic level of practical knowledge and judgment that we all need to help us live in a reasonable and safe way”. 

De flesta av oss har lärt oss att sträva efter att vara effektiva på jobbet. Att implementera processer är en del av den strävan. Processer reducerar risken i en organisation, men varje lager av processer reducerar också förmågan att vara agil och lean, och kanske framförallt förmågan att vara anpassningsbar till möjligheter och hot.

Men i en snabbt föränderlig värld där vi inte längre kan förutspå framtiden och prognoser inte håller så borde fokus skifta till flexibilitet och motståndskraft.

Med tanke på ovanstående, så skulle jag vilja påstå att vi helt enkelt inte längre ska ha effektivitet som ledstjärna och ett mål att sträva efter. Det kanske till och med är tvärtom?

I mitt tidigare yrke utvärderade jag kompetenser i relation till deras yrke och i mötet identifiera eventuella funktionsvariationer genom en dialog med personen i fråga. Det var en nödvändig analys för att kunna bedöma vilken insats som behövdes i nästkommande anställning. Att hantera människor med olika typer av funktionsvariationer kräver en viss kompetens som jag erhöll i mötet med kunderna men även genom internutbildningar av psykologer. Lärdomar om människors kroppsspråk och känslouttryck för att förbättra min egen kommunikation har varit ovärderliga insikter.  Efter tio år i yrket har jag mer än 8000 arbetstimmar i dialog med kund, där jag behövt applicera dessa kunskaper i varje enskilt möte. 

Jag beskriver arbetstiden för att ge dig som läsare en bättre bakgrund av min yrkesnivå och kunskap av människors dagliga kamp i den utsatta situation som det innebär att inte längre upprätthålla Status Quo i form av en anställning.

In December last year I had the fortune to become part of a development team. The last few years my position haven’t “allowed me” to work in a team set-up, that a scrum team embodies. I came to realize how much I’ve missed it! The social aspect and the support that a team really creates became obvious to me.  

The Need to Belong 

The Need to Belong is the strongest one of the drives and the easiest (relatively speaking) way to drive a person forward to the end goal and success.  It might sound simple (common sense) when you read it to understand that we are social animals and thus want to belong to other humans that we feel that we belong to.  

But what is the downside of this human drive?  

Well, ask yourself these questions: 

• Will the team members question the team manager or others within the team?  
• Will they “question status quo” if they feel something is skewed or off?  

Well, this drive hampers that possibility. Since questioning might put you outside of the group and working against the need for belonging.  

Robert summoned it up very well in that we tend to go all in and soon thereafter fail in a grand way.  Don’t get me wrong. I would argue that it is good to fail, and people do that every day as a part of everyday life. If I am not mistaken, Google admits that they fail nine times out of ten.  

Do not forget that you daily fail in repetitive tasks that you thought you already did perfectly. And that’s because you're human. Humans are not robots. 

Through failure we find understanding about what works in what we currently are testing out. That is true even when quitting a use of a drug. We try and try again to quit smoking. Most people succeed. 

So, what is it that Robert is talking about? 

A new year and with that comes New Year´s resolutions! The ultimate “Challenge Status Quo”! 

"2020, THIS will be the year that I will … "

... and then you go “all in” with the ambition to c

hange “everything”. But by March you have lost your stamina and you are back doing what you’ve always done. Does that feel familiar? 

I can see similarities to how business initiatives are approached - It’s quite often that you go in with an “all in” approach, things should be by the book full steam ahead, and less consideration is done to the specific context and common sense is easily left aside.  

So, why do we do this?  

Have you ever felt like your company is going nowhere with its IT development or struggling to pick up pace? Have you had a frustrating conversation with coworkers about the topic, “Why are we not moving forward more quickly? “. Well, it might just have to do with a number of mental models that humans create in their own head to make the person more effective throughout the day. 

Thus, the known expression “It is hard to teach an old dog to sit! “.

Ni har väl hört uttrycket – man äter med ögonen? Maten ska inte bara smaka bra den ska också se god och tilltalande ut för den som äter den. Ibland glöms just detta bort.

Om jag ska göra en köttfärssås till min 7 åring så har jag i massor med grönsaker, men min erfarenhet säger mig att för att undvika diskussioner kring vad som är i och istället ha fokus på hur god den är så mixar jag grönsakerna. Jag anpassar min presentation till målgruppen så att fokus hamnar rätt.

På samma sätt är det med krav - bara för att informationen finns där och till och med är rätt så betyder det inte att den visas upp. Både detaljeringsnivå och syntax bör anpassas, då både målgrupp och mognad/tidpunkt spelar en roll i utformningen.

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?

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.

Så var det nytt år och dags för Kravbloggen att komma igång igen. Själv har jag haft en lugn jul och gott om tid att tänka och reflektera över allt som hänt under 2015. Det kommer antagligen bli ett par blogginlägg om det inom kort. Fram tills dess skulle jag vilja passa på att tipsa om Kravdagen 2016 där jag kommer att tala.

På sista tiden har det pågått lite diskussion om use cases (UC) och user stories (US). När ska man använda vad och vad är för- och nackdelarna med respektive metod. I det här inlägget kommer jag inte gå in på några djupa detaljer om detta utan jag vill dela med mig av en intressant upptäckt jag gjorde nyss.

En sak brukar de flesta vara överens om och det är att User Stories handlar om kommunikation. En US är inte bara ett annat sätt att skriva krav på utan det är mer än så. Man tvingas att tillsammans fundera på vilken den verkliga intressenten är och vad som faktiskt är dennes verkliga behov. Därför är det viktigt att arbetet med att formulera US är en gemensam aktivitet med representanter från alla delar av projektet. Tyvärr är det ju så att metoder kan missförstås (och ibland missbrukas medvetet)...

As Business analysts or analysts working with requirements, we often think that in most organisations and projects, there is a business analyst working between the business and IT to collect the requirements, document them and communicate them to the developers. In ideal world this should be the case but it’s unfortunately not always the case.

I början av sommaren skrev Alexander von Essen ett inlägg om elefanten i rummet. Jag har inte bara noterat elefanten i fråga, utan också till och från känt något tungt som klampar mig på foten.

Det får nog anses vara smått ironiskt att kravområdet, som till del handlar om kommunikation, saknar ett överenskommet språkbruk. Utöver behovet av ett gemensamt vokabulär i allmänhet, tycker jag också att det är viktigt att vokabuläret finns på svenska, eftersom det är det språk som många av oss använder i det dagliga arbetet. Arbetar man på en myndighet är det inte ens förhandlingsbart; Språklagen (lag 2009:600) föreskriver att svenska ska användas och att myndigheter har ett särskilt ansvar för att svensk terminologi utvecklas inom deras olika fackområden.

Nu ska jag slå in en öppen dörr.
Eller är den verkligen öppen?
Jag gissar att den snarare är vidöppen i början av ett projekt eller ett initiativ, men att den bommas igen fullständigt så fort förstudien är klar och man börjat leverera (eller så fort man börjar jobba lite mer fokuserat med backlogen om vi tillåter oss att vara lite mer agila).

Det handlar nämligen om koppling strategi-krav.

Jag har varit ett fan av Gojko Adzic och hans idéer under en längre tid och intresset blev knappast svalare efter hans föreläsning på Kravdagen 2015; ”How to thrive with a flexible scope”. Jag tänkte därför skriva en kort recension av en av hans böcker, nämligen ”Fifty quick ideas to improve your user stories.”

Om du inte tycker att metoder och modeller är jättespännande, så kan du hoppa över att läsa detta lilla blogginlägg, men om du, precis som undertecknad, tycker att metoder och modeller faktiskt är ganska bra att ha tillhands, fortsätt läs!
Som kravare eller BA är metoder och modeller ett viktigt arbetsredskap och det gäller att hela tiden bygga på sin verktygslåda. Jag antar att du redan har så pass många metoder och modeller att plocka fram, att du tappat räkningen. Jag har det i alla fall, men just därför slänger vi upp en ny på bordet!

Begreppsförvirring har vi skrivit om flera gånger i den här bloggen men jag tror ni klarar av ett inlägg till. I takt med att agil utveckling blir mer och mer populärt har även användandet av User stories ökat ordentligt. Många verkar dock inte riktigt veta vad en User Story verkligen är. Och hur skiljer den sig egentligen mot ett Use Case?

För några år sedan gjorde jag en oväntad upptäckt: Utvecklarna på företaget jag arbetade för var mycket bättre på workshopteknik än projektledarna och kravhanterarna. Detta trots att det var vi som satt i flest workshops. Hur kunde det bli så?

En sak som slår mig när jag går på kurs och vi gör gruppövningar för att träna på det vi lärt oss är  - att vi inte lever som vi lär...

När vi jobbar med krav betonar vi vikten av att det finns en workshopledare/moderator som leder de olika mötena under kravarbetet. Sedan går vi på kurs och ska öva på olika metoder inom kravarbetet men då står vi där plötsligt några människor och ska jobba ihop utan någon som leder jobbet.

Förutom jobbet som business analyst eller kravanlytiker gör jag också något lite mer annorlunda, nämligen skriver musik till bland annat tv-spel. För någon dag sen funderade jag lite på hur kraven egentligen ser ut i den världen. I det här fallet är ju jag nämligen leverantör och därmed mottagare av kravspecar.

Så hur kravställer man så abstrakta saker som musik? Hur sätter man siffror på känslor och upplevelser, på ljudbilder, pianon och stråkar? Vad är ”bra musik”?

Spotify kommer att få konkurrens av Apple och deras nya musiktjänst Apple Music som har premiär i slutet av juni (under hösten för Android-lurarna). Priset ska enligt uppgift hamna på samma nivå som Spotifys tjänst. Dock ingen gratisvariant utan enbart tre månader gratis try-out, men då med full funktionalitet.

Spotify har ca 20 miljoner betalande kunder. Under de tre sista månaderna år 2014, vilket också är de tre första månaderna i Apples räkenskapsår för 2015, sålde Apple 74,5 miljoner iPhones. 34.000 telefoner i timmen. 34.000 potentiella användare av den nya musiktjänsten. Per timme. Och i höst får alla med Android också möjlighet att testa den nya streamingtjänsten.

Hej Branschen,

Jag är inte helt säker, men jag tror att det står en elefant i rummet! Ni vet en sån där jobbig grej som alla vet finns men som ingen vågar nämna för man är inte säker på att de andra ser den. Jag ser den i alla fall. Jag ska beskriva den, så får vi se om ni också tycker att det är en elefant, eller om det kanske bara är en dammråtta.

Elefanten jag pratar om är det här med terminologi för kravhantering. I vårt arbete svänger vi oss med en massa fina ord för att beskriva saker och utgår från att alla andra förstår vad vi menar. Men är det alltid så? Nej, självklart inte. Efter 10 år som kravhanterare har jag kommit att inse att många av oss faktiskt använder ord väldigt olika.

I höstas i pausen på en konferens började jag prata med några kravanalytiker. Det var äldre herrar som alla kom från ett större bolag. När jag berättade att även jag jobbar med krav blev de förskräckta. Hur kan jag som ung välja en så mossig bana? Varför skulle en person som läst en civilingenjörsutbildning välja att arbeta med något på en så låg nivå? Hela världen är ju öppen! Möjligheterna är oändliga! Så varför?

I mitt förra blogginlägg beskrev jag kort kraven som ställdes på det nyöppnade Malmökontoret. I detta inlägg tänkte jag kika lite på den köksrenovering som jag nyligen gått igenom. Med mycket möda och stort besvär.
Om man fokuserar lite på de olika faserna, de olika kraven samt hur dessa kommunicerades, så såg det ut ungefär såhär:

Fas 1 - behovet uppstår.

En lång fas. Flera år faktiskt. Fördelar och nackdelar vägs mot varandra.
Behövs ett nytt kök? Det vi har funkar ju fortfarande!
Jo, men ekluckorna känns lite mörka.
Jo, det har du ju rätt i.
Olika typer av inspiration inhämtas. Köksbutiker besöks och tidningar, kataloger läses. Ungefärliga priser fås. Ett behov som egentligen är tveksamt om det ens finns börjar byggas upp. Lobbyingverksamheter startas.
Till slut så formar sig ett business case i huvudet där nyttorna överväger den uppskattade kostnaden. Ett beslut tas; vi behöver ett nytt kök. Efter att man tänkt tanken och pratat om det i olika sammanhang så känns det helt plötsligt självklart och dessutom lite tidspressat. Vi måste ju ha det klart innan Påsk.

Reflekterade häromdagen kring olika typer av krav och hur dessa kommuniceras under de olika faserna av ett renoveringsarbete. Detta i ett läge då dels Require AB öppnat ett nytt kontor i Malmö med undertecknad som kontorschef och dels då jag privat precis gått igenom en köksrenovering.

Om vi börjar med det nya kontoret, så ställdes bl.a. följande krav på hyresvärden efter signat kontrakt:

• Uppfräschning av golv och väggar.
• Inredning i form av;
  • sittplatser för tre-fyra personer.
  • ett lite större bord inklusive stolar avsett för möten, diskussioner.
• Städning någon gång i veckan.
• Möjlighet att ordna kaffe på kontoret.

Något jag ofta får höra på företag som använder sig av olika sätt att modellera krav och processer är ”men så där ska man inte använda den modellen” eller ”den där informationen ska inte vara med i en sån modell”.

Jag förstår egentligen varför dessa kommentarer uppstår. Man har lärt sig notationen för en modell och hur den ska användas och då strävar man förstås efter att folk inte ska göra fel. Men för mig är det helt fel inställning till användandet av modeller.

Hej!

Vi börjar den här veckan med några av de bloggposter jag tyckt varit bra den senaste veckan. Fortsätt gärna tipsa om bra bloggar om kravhantering och business analysis.

Vi har tidigare här på kravbloggen roat oss med exempel ur verkligheten på produkter som hade tjänat gott på en bättre kravhantering. Kravspecificering och produktverifiering kan vara synnerligen välgjorda, men om produkten eller tjänsten sedan inte fungerar i praktiken för kunden är den inte lyckad. Man bör helt enkelt säkerställa att man både har designat produkten rätt och har designat rätt produkt.

Jag tar återigen och tipsar om några av de bättre blogginläggen jag läst den senaste veckan. Tips på bra bloggar att följa inom Business Analysis eller Kravhantering mottages tacksamt, man kan aldrig få för mycket av bra reflektioner.

Kravhantering är ju en central och självklar del av all produkt- och tjänsteutveckling. Gedigna analyser av kundbehov och kundbeteenden är a och o för att kunna kravställa och utveckla rätt produkt som fyller ett behov. Det finns många olika verktyg och metoder för att vaska fram kravbilden. Men i det här inlägget tänkte vi specifikt se lite närmare på riskanalysen som ett sätt att säkerställa kravspecificeringen.

Då och då, efter att noggrant ha gjort sin BA-analys, inser man att den bästa lösningsapproachen givet de mest kritiska kraven och de begränsningar som finns i projektet inte ger någon vettig ROI. Men projektet har ett sådant momentum och driv att de har svårt att stanna upp och inse detta. I andra fall har projektsponsorn verkligen bestämt sig för att det är det här som ska genomföras och ser därför inte de negativa konsekvenserna.

Under 2014 delade vi ett flertal välskrivna och tänkvärda gästinlägg här på Kravbloggen.

”Vi hade ju alla experter med i referensgruppen, ändå blev ingen av dem nöjd med lösningen.” Det är vad en av mina uppdragsgivare sa första dagen på ett av mina uppdrag. Min övertygelse är att det var just det som var problemet, de hade alla tekniska experter med, men inga BA-resurser tillsatta för att kommunicera och hantera expertisen.

Här är de fem mest lästa inläggen på Kravbloggen som publicerades under 2014:

Hej!

Såhär inför jul tipsar jag om ytterligare bloggposter som jag tyckte var extra intressanta den senaste veckan. Kom gärna med tips på era favoritbloggar inom krav och BA.

När tiden inte räcker till

Inte alltför sällan känns det som att man inte får nog med tid till sitt arbete med kravhantering, att projektledare och managers ständigt underestimerar tiden det tar att göra det ordentligt. Det ligger en viss sanning i det på många företag och självklart är det så att om man får välja mellan två månader eller tre månader så väljer man det längre alternativet.

Varför håller då inte alla med om att längre tid alltid är bättre?

Har ni någon gång varit med om att någon på ert företag tyckt att en uppgift inte riktigt fungerar så smidigt som den ska och därför kommer till slutsatsen ”vi borde ha ett verktyg för det”? Utan att göra en ordentlig problemanalys och vilka behov man har bestämmer man sig för att ett verktyg är lösningen. Vilket verktyg man väljer baseras på en stor andel gissningar, lösa antaganden och kunskap som ”sitter i väggarna”. Inte alltför förvånande blir dessa projekt oftast mycket dyrare än beräknat.

Tro det eller ej, men det finns fler bloggar om kravhantering och business analysis än Kravbloggen. Vi på Require läser flera av dem kontinuerligt och tänkte därför att det vore en bra idé om att börja tipsa om inte bara andra bra bloggar utan specifika bloggposter som varit extra intressanta under den senaste veckan.

Den här veckan tyckte jag att följande inlägg var extra intressanta eller välskrivna (en del är äldre än en vecka, men jag läste dem den här veckan):

Lagändringar och förenklade rutiner är bra men redan idag skulle Staten kunna spara miljarder bara genom att tänka på hur man formulerar sina krav.

Som jag har skrivit om tidigare så lade Statens Offentliga Utredningar (SOU) fram en rapport med titeln ”Goda Affärer – En strategi för hållbar offentlig upphandling”.

I rapporten nämns många bra förslag som kan underlätta för anbudsgivarna. Självklart stödjer vi åtgärder som tydligare annonsering av upphandlingar och höjda gränsvärden men detta är åtgärder som behöver behandlas politiskt och tar tid att införa. Finns det då inget som kan göras redan nu? Svaret är ett självklart jo.

Nyligen föreläste jag på konferensen ”Från Krav till System” på temat attityder till kravhantering. Här kommer en sammanfattning för alla er som inte var där. Håll till godo!

Jag får ofta frågan om vårt sätt att se på kravhantering fungera ihop med agila utvecklingsmetoder, såsom SCRUM m.fl. Jag förstår självklart vad dem vill veta med frågan men jag har aldrig tyckt att den är särskilt relevant.  Låt mig förklara.

Man startar och driver projekt för att någon vill att något ska bli bättre. Med bättre menar jag

Alla är vi överens om att kommunikation är viktigt när det gäller kravhantering. Vi är nog också ganska överens om att tydlighet är viktigt. Men varför är det så viktigt med tydlighet då? Därför att det är det enda sättet att verkligen förstå varandra.

Men för att båda ska förstå varandra räcker det inte att själv tro att man är tydlig. Det är på just den punkten som många brister. Man kämpar med att vara så tydlig som möjligt, men helt utifrån sitt eget perspektiv. På det sättet förutsätter man att den andra personen har samma kunskap och erfarenhet som en själv, vilket oftast inte är fallet.

Så om vi säger att tydlighet handlar om gemensam förståelse, varför inte prata med de du vill ska uppfatta dig på rätt sätt?

De senaste åren har Scrum varit i ropet inom IT-branschen. Allt fler företag prövar det och överger byråkratiska och fyrkantiga sätt att bedriva utveckling. Ibland beskrivs Scrum som något som löser alla tänkbara problem. Många företag har också stor nytta av det, även om det inte passar alla.

Det finns dock en hake med Scrum. Ofta rullas det ut på utvecklingsavdelningen, och det är här entusiasmen finns. Nu ska utvecklingen ske enligt Scrummetodiken! Lappar sätts upp på tavlor och sprintar införs. Nu ska företaget arbeta agilt! Även test rycks med, det ingår ju numera i sprintarna.

Men vart tog kravhanteringen vägen?

Alla har vi väl handlat i en affär där man scannar in varorna och betalar själv. Inte med en sån handscanner man har med sig, utan vid kassorna. Jag har stött på två system och de är väldigt olika, båda med sina egna brister.

Att kunna förflytta ett antal personer från A till B med hjälp av flygplan är ett funktionellt krav. Antingen går det, eller också inte. Att ta mig halvvägs löser liksom inte mitt problem.

Att göra detsamma utan att någon omkommer känns som något som absolut bör definieras som ett skallkrav. Men vi vet alla att så inte är fallet.  Enligt en artikel i Metro 2009-01-09 är det risken en på 4,2 miljoner att du omkommer av onaturliga orsaker under en flygning. Det betyder att om du flyger 10 gånger per år i 30 år så är risken att du omkommer under någon av de resorna närmare en på 14 000. Nu är det här avrundade siffror och dessutom inte dagsaktuella men ändå!

Ungefär vart fjärde år hamnar jag i diskussioner med vänner och bekanta om på vad man lägger sin röst. Alltså inte vilket parti eller vilka personer man röstar PÅ utan FÖR vilka personer man väljer väg för Sverige.

Låt mig förklara:
Alla som bor och verkar i Sverige tillhör en population som går att identifiera grovt med olika tillhörigheter. I mitt fall är det t.ex. skolbarnsförälder, arbetstagare, son till pensionär, husägare och bilförare.  Du har själv en mängd tillhörigheter och de största och viktigaste är lätta att identifiera. Sedan vänder vi oss till politikerna och frågar hur de planerar ta hand om oss skolbarnsföräldrar, arbetstagare och husägare?

Jag tänkte passa på att tipsa om lite grupper på Linked In där det diskuteras Kravhantering och Business Analysis. Här delar vi mest med oss av våra idéer och tankar kring krav och BA, men det behövs även mer fri diskussion om allt från branschnyheter, forskning och utbildningar till verkliga exempel på både lyckad och misslyckad kravhantering.

När jag håller kurs eller seminarium talar jag ofta om att kravarbete handlar om kommunikation. Möten, interaktioner, minnesanteckningar, presentationer, specifikationer – allt syftar till att mellan människor kommunicera vad som ska byggas och hur det ska fungera.

Från ax till limpa kommer då olika typer av kravbeskrivningar fylla olika syften. Vi talar exempelvis om mål, processkartor, informationsmodeller, kontextdiagram, user stories, användningsfall, UI mockups, systemövergripande kvalitetskrav, etc. Ja, även i en agil värld använder vi nedtecknade ord och bilder!

Nu har jag under mitt första halvår på Require varit i kontakt med en hel del kunder, prospects och även några företag som vi faktiskt inte vet om de jobbar med kravhantering.  Jag har också intervjuat ett antal personer för anställning, talat om för släkt och vänner vad jag jobbar med och försökt vara aktiv i diskussioner och debatter.

Men alla mina kontakter väcker en fråga kring kravhantering – Är vi överens om vad det egentligen är?

En gång när jag för hundratusende gången hos en kund tjatade om att vi måste göra kraven otvetydiga, och helst mätbara, fick jag en raljerande kommentar av en annan konsult i projektet. Han himlade med ögonen och sa nåt i stil med "Ja, ja. Det låter ju bra men det fungerar inte så i praktiken. Det vet jag, för jag har faktiskt jobbat med det här i många år". Vid tillfället kom jag givetvis inte på någon dräpande kommentar men igår kom jag att tänka på händelsen igen, trots att det är ganska många år sedan.

Det som slog mig är att det är en ganska vanlig inställning till specifikationsarbetet. Alltså att det inte är nödvändigt, eller ens önskvärt, att vara tydlig i sina krav. Iallafall när det gäller krav i textform...

Rational Unified Process, eller RUP som det ofta kallas, är knappast något nytt. Det är en mjukvaruutvecklingsapproach som är tänkt att vara iterativ och väldigt use case-fokuserad. Den går att beskriva på en mängd andra sätt också och frågar du två personer vad RUP är får du antagligen inte samma svar. Att använda sig av en strukturerad process är alltid bra och det finns många fördelar med RUP, vilket troligen är anledningen till att så många företag fortfarande stödjer sig på RUP i sin utvecklingsprocess. Men det finns en sak som jag verkligen stör mig på.

Det är lätt att gå från en konferens väldigt inspirerad och motiverad inom ett ämne vilket som helst. Nu har vi precis haft en väldigt lyckad konferens inom kravhantering och det finns en massa inspirerade personer på flera spännande företag runt om i Sverige. Hur tar vi då tillvara på denna inspiration? Och hur implementerar jag det i mitt företag?

Frågeställningen är naturligtvis tvärfunktionell men diskussionen i det här fallet utgår från kravhantering. Och faktum är att kravhantering är en kompetens du som läser detta har men den du pratar med ofta saknar.

Vi är i det här sammanhanget individer och måste utgå från våra förutsättningar och den miljö vi vistas i och dessutom inse att uppgiften vi står inför är tudelad.

1. Att behålla inspirationen själv.
2. Att dela med sig av nyvunnen kunskap.

De båda uppgifterna är i mitt fall nära relaterade då jag behöver stöd från min omgivning för att hålla modet uppe att arbete med inspiration. Alla behöver inte det.

Det finns flera enkla regler att hålla sig till när man ska skriva krav men när man väl sitter där och ska formulera kraven så är det ofta lätt att missa något. Det som är uppenbart för mig när jag skriver kraven är det inte för andra, trots att jag har erfarenhet av och förståelse för att skriva enkla och entydiga krav. Visst kan man fånga det i en granskning av kraven efteråt, men kommunikationen tar längre tid och missförstånd och förklaringar drar ut på tiden. Inte effektivt, och inte roligt.

Kan vi göra rätt från början genom att snabba upp granskning och interaktion?

Ja, genom att skriva krav i par!

“Leaders see more than others see, and leaders see before others see”, säger bästsäljande ledarskapsförfattaren John C. Maxwell.

Att kunna se mer kundbehov än andra är önskvärt. Att se kundbehov före andra är också bra; den som är skicklig på det skaffar sig ett försprång i utvecklingen av sina produkter och tjänster, blir mer innovativ.

Att vara innovativ är att skapa nya, brukbara idéer och genomföra dem.

Mina dagar består väldigt ofta i att försöka övertyga personer och företag om att kravhantering är viktigt. Ett av de vanligaste problemen jag stöter på är att företag fokuserar helt på ny teknik och ser det som nyckeln för att utveckla framtida, konkurrenskraftiga produkter. Jag menar dock att tekniken bara blir värdeskapande om den löser ett visst behov hos intressenterna, och det är ju precis det som kravhantering är bra för – att specificera vad intressenterna vill ha. Vad ska bli bättre, hur mycket bättre och för vem?

Efter att ha tipsat om inledande och förtydligande frågor att ställa till intressenter så avslutar vi med fyra avslutande frågor att ställa vid intressentintervjuer eller andra insamlings- och analyssituationer.

Nu kan du få nya inlägg direkt till mailen, ange mailadress i fältet till höger så kommer nya inlägg skickas ut till dig!

Ett stort problem vid kravinsamling är att väldigt många intressenter gärna pratar lösningar istället för att definiera problemen de har.

Ber man en intressent att säga vad de skulle vilja ha får man oftast svar som ”samma fast lite snabbare/lättare/bättre”. De utgår från den produkt de har idag och lägger gärna till lite funktionalitet. Av någon anledning är det väldigt svårt att se vad som bör förbättras när man ställer en positivt formulerad fråga. ”Säg vad som går att göra så säger jag om det är bra” är ganska vanligt att höra, trots att man idag kan lösa i stort sett vilket problem som helst.

Min dröm är att jag är med och bygger system som användarna tycker om att använda. Som löser deras problem på ett elegant sätt så att de säger ”- Jag hade aldrig trott att det kunde vara så här!” Drömmar av det här slaget kan ju tyckas ouppnåeliga, åtminstone om man ska åstadkomma något på egen hand. Martin Luther King Jr. förespråkade icke-vålds ideologi med inställningen att han vägrade samarbeta med ett orättvist, dåligt system. Det som gjorde att han lyckades uppnå sin dröm, kampen för mänskliga rättigheter att alla behandlas lika oavsett hudfärg, tror jag var att han lyckades göra sin dröm till andras dröm. Jag tror att drömmen om användbara system kan bli sann endast om jag delar den med er andra och gör den till även er dröm.

I mitt förra inlägg tog jag upp några frågor som är bra att ställa när man kommer in i ett projekt. I det här inlägget tar jag upp exempel på frågor som man kan ställa för att få ut mer eller ny information från de intressenter man jobbar med. Ofta handlar det om varianter på samma frågor, men det kan ändå vara bra att ha några i bakhuvudet.

Jag arbetar inom utbildningsbranschen inom IT och är bl a medlem i Dataföreningen. När jag summerar höstens läsning av CS/IDG så slås jag av hur ofta man kan läsa om IT-system som användarna ratar. Storstilade dyra systemprojekt som helt behöver göras om efter kritikerstorm eller helt läggas ner. Polisen och Nordea som två exempel. Det sägs att runt 60-70% av alla startade projekt inte når upp till de uppställda, ursprungliga kriterierna för ett lyckat levererat projekt. (Chaos report, USA).

När man jobbar med att ta fram kraven i ett projekt så försöker man ofta få fram så mycket information som möjligt från intressenterna. Vilka frågor man ska ställa är givetvis beroende på när man kommer in i projektet, vilken roll man har, vem man intervjuar m.m. Några frågor är däremot alltid bra att ställa, för att få ut så mycket relevant information som möjligt om kraven, problemet och lösningen.

I det här inlägget tar jag upp några frågor som är bra att ställa i inledningsfasen när man kommer in och ska jobba med kraven eller verksamhetsanalys i ett projekt.

Här är de fem mest lästa inläggen på Kravbloggen under förra året:

Nu är det nytt år och det är dags för Kravbloggen att vakna efter en kortare julledighet. Vi kommer precis som vanligt fortsätta med intressanta diskussioner, reflektioner och teorier kring kravhantering och en hel del annat.

Den 20/3 2014 hålls den tredje upplagan av Kravdagen, en heldag som ingen som jobbar inom utvecklingsprojekt bör missa.

Kravdagen är en heldag om kravhantering, den här gången med inriktning mot hur kravhantering kan hjälpa företag att bli mer innovativa och kreativa. De tidigare två konferenserna har varit väldigt uppskattade och intresset växer för varje år som går.

Dagen bjuder på sju riktigt spännande föreläsare:

Det blir allt vanligare att företag ser över hur de kan minska sin miljöpåverkan eller bidra till en grönare utveckling. Google köper upp energiföretag som tillverkar förnyelsebar energi, bland annat köper de vindkraft från Sverige för att försörja sin anläggning i Finland. Svenska regeringen meddelade i våras att satsningarna mot gröna investeringar kommer öka framöver.

På ytan kan det verka som det finns många tips och användbara idéer för att göra sitt företag grönare,

Wikipedias artikel om kommunikation inleds med meningen "Kommunikation är en process för att överföra information från en punkt till en annan". Jag menar att kravhantering kan fylla en liknande funktion, en stor anledning att jobba med kraven i sina projekt eller organisationer är just för att säkerställa överföringen av information.

När människor kommunicerar med varandra så utgör de faktiska orden en del av kommunikationen, kroppsspråk och tonfall påverkar utöver orden*, och det finns en mängd andra faktorer som påverkar (Kravexperten har ett inlägg om muntlig och skriftlig kommunikation).

En sak jag märkt är att många företag vid både kravinsamling och utveckling är alldeles för dåliga på att använda modeller. Istället produceras alldeles för långa kravspecifikationer med mer text än någon skulle vilja läsa och definitivt mer än vad som är lätt att förstå.

Jag tänker inte ens gå in på hur fel jag tycker det är med tusensidiga kravspecifikationer, det är ett helt annat blogginlägg. Däremot vill jag slå ett slag för att använda modeller oftare för att förtydliga krav. Vi människor har ett väldigt högt visuellt lärande och det borde utnyttjas för att lättare komma överens om krav med projektets intressenter.

Nästan alltid när vi pratar om kravhantering så gäller det utveckling av produkter av något slag. Ofta IT-system. En aspekt av kravhantering som däremot ofta hamnar i skymundan är dess roll i upphandling. Det tycker jag är tråkigt. Företag och organisationer har jättemycket att vinna på att se över hur de specificerar sina krav i upphandlingar. Detta gäller i synnerhet våra Statliga verk, som upphandlar varor och tjänster för många miljarder varje år.
I våras blev Statens Offentliga Utredningar (SOU) klara med en 700 sidor lång rapport där de analyserat problem och förbättringsområden i Svensk offentlig upphandling. Självklart handlar den inte bara om krav men en av de tyngsta punkterna är faktiskt att myndigheterna har mycket pengar att spara på att arbeta bättre med krav och kravhantering.

Hej!

Under november månad får Require en ny medarbetare i form av mig, Anders Erlandsson. Jag har påbörjat resan med att lära känna alla medarbetare och dessutom branschen som sådan. Och det blir en del reflekterande eller snudd på filosofiska samtal. Jag har också börjat prata med vänner och bekanta om kravhantering och frågat hur de jobbar med det på sina företag.

Det har lett till en frågeställning som låter ungefär såhär:

Häromdagen fick jag frågan varför jag började arbeta med kravhantering. När jag tänkt på det en stund inser jag att det bara är jag av alla de jag läste med på högskolan som idag arbetar med kravhantering, åtminstone den enda som vet om att jag gör det. Jag läste Maskinteknik på KTH, med inriktning Integrerad Produktutveckling. Där kom jag i kontakt med kravhantering för första gången. Vi genomförde ett riktigt utvecklingsprojekt av en bärbar översvämningspump som projektarbete och där blev jag delvis ansvarig för att ta fram kraven.

Många gånger får jag frågan om hur få/många krav man bör ha i sitt projekt. Det är en fråga som är väldigt svår att svara på. Alternativt blir svaret något så luddigt som ”precis lagom många”. Jag är dock av den bestämda åsikten att alldeles för många projekt specificerar på en alltför detaljerad nivå. Det går inte att styra efter hur mycket som helst. För många krav gör att det blir omöjligt att vara effektiv. Konsten är att kunna skapa en modell av vad som ska utvecklas med precis sån detaljnivå att alla förstår. Det får varken bli så mycket att alla drunknar i krav i onödan och det får inte bli en så förenklad bild att den inte är användbar.

I den här artikeln beskriver författaren en alternativ metod till "traditionell" kravinsamling. "Traditionell" kravinsamling hänvisar här till en kort, fristående aktivitet i början av ett projekt som resulterar i en dåligt underbygg kravspec som sedan inte ändras eller knappt används i projektet. Jag håller med om att en sådan kravinsamling är helt fel och i princip håller jag med om författarens alternativa metodbeskrivning.

Däremot är det som vanligt i de allra flesta IT-projekt enbart fokus på funktioner, eller egentligen inte ens funktioner. Det exempel som beskrivs är ju en direkt lösning på ett problem. Författarens metod löser detta delvis genom att beskriva ett sätt att effektivt och iterativt testa att den lösning man håller på att ta fram genererar värde för intressenterna.

I kommentarerna till mitt förra inlägg här på kravbloggen så tycker jag att det blir tydligt att kravhantering har lite olika syften i olika skeden i ett projekt. Till att börja med är det givetvis viktigt att ha kontroll på kraven och dess kvalitet under projektets gång. Man måste ha en tillräckligt detaljerad kravspec för att kunna utveckla eller handla upp.

Däremot tror jag att kravhanteringens roll i de tidigare skedena ofta missas eller förbises och här tror jag att det finns stora vinster att göra. Jag tror också att kravhanteringsdisciplin i sig har mycket att vinna på att snegla på andra områden, t.ex. Lean Product Development (LPD) och Lean Startup. Just kopplingen till olika Lean-filosofier tror jag kan föra kravhanteringen framåt en bra bit.

En sak jag stöter på väldigt ofta är att en stor del av kraven i en specifikation aldrig riktigt valideras av de faktiska intressenterna, det vill säga att kraven verkligen täcker deras specifika behov. Även om mycket tid läggs på själva intressentanalysen och/eller behovsinsamlingen finns det en mängd fel som kan uppstå när behoven omvandlas till faktiska krav. Tolkningar görs, språket används på olika sätt, formuleringar och ord ändras. Det är inte alls säkert att de behov som man så noggrant samlade in nu är fullständigt representerade i den färdiga kravspecifikationen. Resultatet blir ett system som inte motsvarar intressenternas förväntningar.

Vi letar nu efter personer som vill skriva gästinlägg i Kravbloggen, så att det blir ännu mer diskussion och fler intressanta synvinklar.

”Ekonomi handlar om att skapa nytta och värde genom att hushålla med och effektivt använda resurser.” Citatet kommer från en grundläggande lärobok om företagsekonomi. Definitionen består av två delar. Dels syftar ekonomi på att skapa nytta och värde och dels ska det göras med ett effektivt utnyttjande av resurser.

En annan tes från företagsekonomin säger att det företag som producerar den bästa tjänsten eller produkten med minst utnyttjande av resurser kommer att klara sig bäst.

Det finns idag ett otroligt fokus på funktioner hos de flesta utvecklande företag. De funktionella kraven tar nästan all tid, trots att det faktiskt inte är funktioner som gör produkten konkurrenskraftig, åtminstone inte till största delen. Alla grävskopor kan gräva. Det som skapar konkurrensfördel är hur bra den gräver, till vilken kostnad, bränsleåtgång och så vidare.

Trots det är fokus är så stenhårt inriktat på funktioner att de krav som inte är funktionella krav kallas i litteraturen för de ”icke funktionella kraven”. Det beskriver alltså bara vad de inte är? De får inte ens ett eget namn. Det är de funktionella kraven – och så de där som inte är det.

Allt fler organisationer köper och implementerar nyare kravhanteringsverktyg. Det finns i dagsläget stor valmöjlighet vad gäller verktyg och konkurrensen mellan dessa blir tuffare och tuffare. Detta är förståeligt då allt fler börjar se stor nytta med dem. Det är såklart en positiv utveckling för oss som tycker om kravhantering och det är helt klart hälsosamt att Office-paketet får lite konkurrens.

Kravhantering är ett relativt nytt område att specialisera sig inom, och det märker man på utbudet och innehållet i de böcker som finns om ämnet. De flesta böckerna handlar om kravhantering för IT, men några böcker hanterar kravhantering som ett mer universellt område. Jag har läst tre sinsemellan olika böcker, Kravhantering för IT-system, Mastering the Requirements Process och Systems Engineering: Priniciples and Practice.

Om man säger ordet projekt så finns det säkert lika många definitioner som det finns personer som använder ordet. Iallafall är det väldigt olika hur begreppet används på olika företag. Visst finns det definitioner men ordet är nog ändå ett av de mest missbrukade orden i svenska språket. Dessutom finns det nästan lika många projektstyrningsmetoder som det finns åsikter om projekt.
Trots alla dessa skillnader anser jag att det finns några saker som alla har gemensamt. Det har nämligen visat sig i studier att det finns fem faktorer eller aktiviteter som man inte får glömma i ett projekt, oavsett storlek, bransch eller styrmetod. Exakt hur dessa aktiviteter hanteras kan variera kraftigt men att man har en strategi för dem är absolut nödvändigt. Jag har valt att kalla dem Fem Faktorer för Framgång.

Som ny inom kravhantering har jag fått flera frågor om vad kravhantering egentligen är, och om det inte är något man bara sysslar med inom systemutveckling. Precis som med många andra saker så är det först när man börjar jobba med det som man ser hur vanligt det faktiskt är.

Kravhantering handlar om att identifiera intressenterna, och att specificera intressenternas förväntningar på uppgiften eller produkten. De är först när man vet vilka som är berörda av produkten och vad de vill ha ut av den som man kan ta fram förslag på hur man når dit.

Ett problem många företag som ska utveckla en ny produkt har är att de utgår från den produkt de har på marknaden idag – ”Vi utvecklar samma fast bättre”. I praktiken innebär det att man tar sin gamla produkt och lägger till lite funktionalitet eller förbättrar prestandan något.

Jag anser att det är helt fel väg att gå. Man blir inte världsledande på det sättet. Varför ska man överhuvudtaget utgå från en produkt som redan är gammal? Den stora utmaningen ligger i att definiera vad som behövs i framtiden, oavsett tidigare produkter.

Hej och välkommen till Kravbloggen!