Under en lunch för inte så länge sen hamnade jag och en kollega i diskussionen om paragrafryttare, de som ska följa varenda liten skrivelse i ett ramverk konstant för att annars ’bryter vi mot ramverket’. Under konversationen sa jag att eftersom jag är en person med ’regler är till för att brytas’-mentalitet, kan man väl säga att jag har väldigt svårt att klicka med personer som alltid ska ha regelboken i högsta hugg och vägrar tumma på linjen.

Så kom frågan, ’Men Kattarina, du är ju kravanalytiker, du skriver ju krav som i princip är regler, hur går det ihop?’ – Jo det ska jag försöka svara på.

I mitt senaste projekt jobbade jag som kravanalytiker i ett stort agilt team tillsammans med ett gäng utvecklare, testare och UXare. Vi alla var nya i teamet och vi alla var lite osäkra på våra olika ansvarsområden. Framför allt mellan mig som Business Analyst (BA) och UX. Var går egentligen gränsen mellan vad en BA hämtar in för krav och vad en UXare hämtar in för krav? Visst känns det ibland som om rollerna överlappar varandra?

Jag har haft möjligheten att jobba med Microsofts PowerApps. En fantastiskt rolig och förhållandevis enkel möjliggörare för att få ut saker snabbt. Den har dock sina begränsningar.

Under ett av mina uppdrag hamnade jag i ett väldigt intressant och lärorikt sammanhang – jag reflekterade mycket över detta projekt och hur vi gjorde saker och när jag beskrev det för mina kollegor insåg jag ännu mer hur unik denna erfarenhet var.

Det finns en omtalad studie på schimpanser från 60- eller 70-talet som ibland återges i olika sammanhang. I studien släpps 20 schimpanser in i en stor sal som är tom så när som på en stege och en klase bananer som hänger strax ovanför stegen. Det dröjer inte länge förrän några schimpanser upptäcker bananerna och sätter av mot stegen. Så snart den första schimpansen tar tag i stegen duschas hela salen i iskallt vatten. Chockade av denna djupt obehagliga upplevelse faller alla aporna till marken.

Efter en stund repar sig de flesta och ytterligare en gång beger sig ett par av schimpanserna mot bananerna. Så snart stegen vidrörs upprepas samma iskalla dusch av alla schimpanser och nu är det några apor som ser en koppling mellan att vidröra stegen och att få en kalldusch. Det gäller dock inte alla, och en av de som inte förstått hur det hänger ihop sätter av mot stegen.

Jag är ingen psykolog och har inte studerat heuristik akademiskt men jag har jobbat i drygt tjugo år på olika sidor av ”bordet”, presenterat saker i olika forum, bett andra ta beslut, varit den som tagit beslut och funderat på hur saker ska vara. Och det har fått mig att reflektera över varför man ibland tänker, tycker och beter sig som man gör som individ, i grupp och mot individer/grupper.

En återkommande och vanligt använd teknik för att hitta en rotorsak är ”5 Varför”. Tekniken baserar sig på att man fem gånger frågar efter varför ett fel har uppstått, och genom det kan man hitta rotorsaken till felet.

I denna blogg redovisar vi resultatet av en enkät där vi ställde frågor till våra konsulter rörande Beroende – vilka typer av beroenden ser vi på våra uppdrag, hur påverkar de det dagliga arbetet, och hur hanteras de?

Vet ni skillnaden mellan korrelation och kausalitet?

• Korrelation – Om det finns ett samband mellan två eller fler faktorer säger man att de korrelerar. Korrelation innebär inte nödvändigtvis att det finns ett orsakssamband (kausalitet). De kan båda vara påverkade av en tredje faktor eller så kan sambandet bero på slumpen. 

När vi ska byta bostad måste vi planera, samla och gå igenom våra behov och besluta oss för vad vi ska ta med i flytten och vad som eventuellt måste justeras i den nya bostaden innan flytt.

När vi byter från ett system vi arbetar i till ett annat ställs vi inför samma typ av frågor; vad ska vi ta med, vad kan vi lämna kvar och vad behöver vi modifiera?

Du har din bostad som du känner så väl och kanske en hel del saker i skåp och lådor som du sällan eller aldrig använder. Ska du ta med dig dessa till den nya bostaden eller ska du lämna kvar (sälja eller ge bort) dem. När du står inför flytt av system kan det vara dags att titta på din data och datamodell, flytta inte en röra utan strukturera upp så du får bra datakvalitet i ditt nya system och kanske kan du även här rensa bort en del som inte används.

När du lagar mat ökar dina chanser att rätten som du håller på att laga blir god och tilltalande genom att du följer ett recept. Ett bra smaksinne samt att du har instinkt för smaker och en visuellt konstnärlig ådra kan också bidra. Men matlagning i en perfekt miljö där inget oväntat händer eller en kock som lagar mat utan recept eller kunskap, med enbart rå talang är ganska unikt. Jag skulle inte anlita en sådan kock. Skulle du?

Så vad är det vi letar efter? Är det inte erfarenhet?

I många fall behöver inte erfarenhet vara något som en specifik individ innehar och den behöver inte vara självupplevd. Erfarenhet kan vara kollektiv.

Som du kan se nedan, i min kategorisering av punkterna, så är det upp till dig men också din organisations / teams / nätverks ”ansvar” att skapa och ta till sig dessa erfarenhetskomponenter.

Så vad är erfarenhet, enligt mig?

För ett tag sedan lyssnade jag på avsnittet ”Om Expressensvenskan” i podden ”Snedtänkt” med Kalle Lind. Det fick mig att fundera om vi som verksamhets- och kravanalytiker kan lära oss något från ”expressensvenskan” för att bli tydligare i hur vi uttrycker oss?

Som konsulter kommer vi in i vitt skilda verksamheter med uppdraget att analysera ett nuläge och få någon form av förändring till stånd. I samband med Corona-pandemin har vi tagit tillfället i akt att se över vår egen verksamhet med hjälp av metoder som vi använder i uppdragen.  

I våras byggde vi trall och terrass här hemma. Under arbetes gång blev det uppenbart för mig hur mycket likhet detta bygge hade med agil mjukvaruutveckling. Flera koncept som jag precis läst om under min SAFe-certifiering tillämpades i praktiken.

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: