SPISEC-metoden

Hur stoppar man de som skjuter från höften innan de förstått situationen och problemen?

Många projekt lider av Cowboy-syndromet. Man tror att den som snabbast drar fram en eller flera lösningar vinner. Man ”skjuter från höften” och hoppas på det bästa.

Men Trigger-happy solutions är sällan effektiva eller revolutionerande. De är bara snabba. Ofta ganska dumma och kostar nästan alltid mer i slutändan.

Osmart och oagilt helt enkelt!

Projekt handlar sällan enbart om att leverera tekniska detaljerade lösningar eller ”ändringar i en drop-down”, utan kräver ofta en effektiv genomlysning av de involverade  strategiska automatisk systemen i organisationen och hur alla intressenter beter sig, hur de tänker och hur de upplever den aktuella situationen.

Om en person, som representerande en roll eller en specifik  målgrupp) upplever ett problem i den givna situationen och kan förklara hur detta problem kan få en negativ inverkan på organisationen inom kort eller på lång sikt, så gäller det för alla projektmedlemmar att förstå och representera detta på bästa möjliga sätt. 

luckyLuke.png

Trigger-happy solutions funkar enbart om du drar snabbare än din egen skugga!

Annars kommer varje ny lösning få oanade konsekvenser med en

överhängande risk för suboptimering där den lilla lokala ”förbättringen”

genererar en försämring för helheten och allt runtomkring.

Man kan se på verkligheten från flera olika håll !

För en person, som representerar en annan roll eller målgrupp, har kanske en helt annan bild av situationen, vilket innebär att ”problemet” kanske till och med upplevs som något positivt för denna grupp och att de negativa effekterna som andra försöker lyfta fram upplevs som starkt överdrivna.

Valet av VY kommer således starkt påverka lösningsmängden. Många lösningar löser helt enkelt inte de riktiga problemen, eftersom dessa inte ens blivit varken identifierade eller korrekt representerade!

Det huvudsakliga syftet med att förstå den verklighet som respektive målgrupp upplever, är att kunna sammanställa en ””lista” med Identifierade Upptäckter, (findings) och att kunna förklara dem och resonera kring dessa och de ursprungliga behoven.

Utifrån en helhetssyn kring alla representerade Upptäckter kan organisationen definiera ett antal rekommenderade åtgärder (lösningar) som verkligen löser de  utvalda problemen och  som kan prioriteras med avseende på strategisk nytta och kommande förvaltningsaktiviteter etc.

Hur ska man representera denna förståelse på ett enkelt sätt och vilka frågor bör man ställa?

SPI(SEC).jpg

SPISEC fokuserar på det som varje framslängt påstående MÅSTE konfronteras med.

Om någon del saknas är påståendet inte tillräckligt moget.

SPISEC =  Good enough!

Varje Problem är endast ett problem i en specifik situation

Varje Problem är ett problem i en specifik situation för en specifik person, roll eller målgrupp och problemet är ett problem eftersom det har en inneboende negativ konsekvenskedja som kan utlösas om man inte gör något åt själva problemet!

När man förstått SPI-delen, brukar det dyka upp flera möjliga lösningar.

Men varje lösning måste knytas till själva problemet, den specifika situationen, problemet/problemen, intressenten och den negativa konsekvenskedjan genom en tydlig positiv konsekvenskedja med möjliga positiva effekter (som ger nytta för den givna intressenten). Den som levererar lösningen måste också formulera och beskriva hur världen ser ut när den positiva lösningen genomförts och fått verka fullt ut. Först då har vi en tillräckligt bra förståelse för att dra fram och sätta igång lösningsmaskineriet!

----------------------------------------------------------------------------------------------------------------------

I den specifika situationen av att ...<Specifik Situation>

... är <problemets namn> ett problem och en utmaning för  <rollen som har problemet>

... Problemet är en del av en  konsekvenskedja som leder till ett antal möjliga negativa effekter enligt:  <Problemkedja med negativa effekter>

En (första) identifierad möjlig lösning skulle kunna vara att: <möjlig lösning>

Denna rekommenderade lösningen skulle kunna ha följande nytta/positiva effekt och lösningskedja: < positiv effekt & lösningskedja >

... och lösningen kan betraktas som tillräckligt bra när följande nöjdhetsvillkor uppfylls: <nöjdhetsvillkor>

----------------------------------------------------------------------------------------------------------------------

SPISEC tabell.png

SPISEC på tabellformat.SPI-delen är första steget mot förståelse

med fokus på problemet och dess konsekvenser. 

SEC-delen (som kan vara flera till samma SPI) förtydligar möjliga lösningar,

dess positiva effekter och hur man kan veta att man lyckats .

SPI-image.png

Innan man skjuter från höften och rusar in i ”lösningslandet”, så måste man

utforska och förtydliga SPI, genom att ställa frågor inom varje område:

Situations frågor, Problem frågor  och Inverkansfrågor.

“Customers are not happy with a product just because they

understand the product  and its capabilities, but because

they felt that the requirements team understood and

addressed their real needs and problems”

SPISEC frågor

För att fånga de olika aspekterna kring SPISEC gäller det att ställa rätt typ av frågor. Frågor som är öppna och som får intressenterna att beskriva hur de upplever och ser på sin verklighet. ”Varför-frågor” är stängda frågor som tvingar fram förklaringar snarare än beskrivningar av personens inre karta och bilder. Oftast upplevs ”varför-frågor” som en direkt eller indirekt attack på intressentens värdegrund eller vad han/hon tror på. Svaren på varför-frågor blir därför i regel korta defensiva formuleringar skapade för att passa in i formatet skapat av frågeställaren och för att slippa mer frågor. Tvärtemot vad vi egentligen vill ha. För att verkligen förstå måste vi vandra hand i hand i intressentens tolkning av omvärlden och göra en gemensam upptäckresa. SPISEC frågorna är öppna frågor som skapar riktig förståelse och verkliga lösningar!

Situations frågor (Situation Questions):

Samla in lämpliga faktauppgifter och ställ sedan frågor som får intressenten att beskriva hur de upplever sin situation. Hur ser verkligheten ut i deras ögon. Om man skulle ta foton eller filma situationen, vad skulle man skriva under bilderna. Vad är det som foton och film inte kan fånga? En del av situationsbeskrivningarna är faktauppgifter. Exempel på en fakta-fras: ”företaget har 612 anställda uppdelade på 7 olika avdelningar där varje avdelning har en avdelningschef”. Hur mycket fakta finns att tillgå som kan måla tavlan tydligare? Hur säker kan vi vara på att denna fakta är korrekt? Vem är källan? Intressentens egna upplevelser behöver inte vara faktagranskade, varje person äger sin egen tolkning av verkligheten och den är ”korrekt” för den personen. Det måste alltid respekteras!

Problem frågor (Problem Questions):

Ställ frågor som får intressenten att prata om var och på vilket sätt  “det gör ont” och detaljera problemet så att det spelar huvudrollen i intressentens mentala tillstånd. Bakom problemen hittar man ofta de verkliga behoven! Notera att problemet är ett problem för just denna intressent i denna specifika situation. För en annan intressent eller i en något ändrad situation vi en senare tidpunkt, är det kanske inte längre ett problem. Även om problemet försvinner av sig själv måste vi försöka förstå orsaken.

Inverkansfrågor (Negative Implication Questions):

Öppna diskussionen kring vilken effekt som problemen kan leda till, både i nutid och i framtiden. Förankra förståelsen av konsekvenserna hos intressenterna, skapa tillsammans en tydlig bild av hur allvarlig situationen är, så att intressentens VILJA till förändring (och ”köp”) knyts samman med problemen och banar vägen för längtan efter nyttan med den kommande lösningen.

Konsekvenskedjorna kan modelleras men en förenklad textlogik. Det fungerar bra att använda ”implikations/korrelations pilar” (à) och explicit AND/OR logik medelst ”+”.

Ett exempel på denna ”avslappnade logiska kedja” är följande:

I: om XX inte ger möjlighet till uppladdning av foton --> fångar inte upp det spontana intresset (”WOW såg du vilken fantastiskt blomma som växer precis vid sjön!”) --> XX kopplas inte ihop med friluftsliv i närheten av vatten --> missar chans till lokalt engagemang + missad chans till ökad  ”ansvarskänsla” från allmänheten

Frågor om Idéer och identifierade möjlig lösningar

Fråga intressenterna om deras egna idéer och tankar. Vad skulle de göra om de var omnipotenta med en enorm påse pengar och alla resurser i världen? Om inga begränsningar fanns på projektet, hur skulle en lösning kunna se ut då?

Frågor om löningens konsekvenser, nytta och positiva effekter

Fråga intressenterna om hur ”lösningen” kommer påverka situationen, de identifierade problemen och var lösningen kommer att bryta den negativa konsekvenskedjan som kommer ske om ingen gör något åt själva problemet. Vad har lösningen för möjligheter och vilka andra positiva effekter, förutom själva lösningen av problemet, kommer den att ge upphov till (spin-off effekter)?

Ett exempel på denna ”avslappnade logiska kedja” är följande:

E: Fototävling à stort engagemang bland folk som gillar ” Instagram” och liknande delgivningsappar --> strategisk informationsspridning om XX i dessa grupper + stort antal bilder kommer in på kort tid --> ökat intresse för XX

Nöjdhetsvillkorsfrågor

Hur kommer intressenterna veta att ”lösningen” fungerar? Hur ser världen ut då? Hur kan vi mäta att lösningen varit framme och rensat bort problemen och hur vet vi att lösningen kan betraktas som tillräckligt bra?

Vilka villkor måste vara uppfyllda för att ALLA involverade ska ställa sig upp och göra vågen av glädje för den nya införda lösningen? 

SPISEC kortet är en Identifierad Upptäckt!

Om vi tillför en unik identifierare och ett namn på varje enskild SPISEC, kan vi se varje enhet som en Identifierad Upptäckt (Finding) inom det aktuella arbetsområdet.

SPISEC formatet kan även användas för att få grepp om omfattande kunskapsmängder genom att definiera tydliga identifierade upptäckter (IU). Ett stort material kan ge upphov till hundratals IU, som givetvis har relationer till varandra och kan grupperas, struktureras och visualiseras.

Eftersom varje IU innehåller en eller flera problemkedjor och en eller flera lösningskedjor med positiva effekter, så kan ett större nätverk av konsekvenskedjor byggas upp till en helhetsmodell.

I flera fall räcker det med att gruppera de Identifierade Upptäckterna och att visualisera hur de hänger samman och grupperar sig. Det är smart att använda fem klassiska logiska relationer mellan de olika IU-enheterna:  Obstruction, Conflict, Requires, Support och Equality.

relations.png

Från Identifierade Upptäckter till Förbättringsförslag!

Om man genomför en stor utredning som spänner över ett stort antal dokument och involverar många intressenter, förväntas det oftast att utredningen ska leda fram till ett antal förbättringsförslag (FF!). Men hur ska dessa förslag byggas upp, motiveras och förklaras för alla involverade? Ett effektivt sätt är att spåra alla identifierade Upptäckterna till ett mindre antal Förbättringsförslag. Relationen mellan IU och FF! är givetvis från en eller flera IU till en FF! och varje enskild IU kan stödja

eller bygga upp flera olika FF!

IU-FF tabell.png

Relationerna mellan IU och FF kan representeras visuellt eller i en spårbarhetstabell

Förbättringsförslag!

SPISEC-kortensom representerar Identifierade Upptäckter (IU) leder på ett naturligt sätt fram till Förbättringsförslag (FF!). Men hur ska vi sammanfatta en FF?

IU-FF Flowers.png

Förbättringsförslagen och de associerade Identifierade Upptäckterna kan även visualiseras som

”blommor” där alla IU är som blomblad till varje enskild FF!

På samma sätt som varje enskild SPISEC bör ha en unik identifierare och ett namn, bör även varje förbättringsförslag vara unikt och sammanfattas i en tabell/på ett kort med ett antal obligatoriska rubriker: Involverade roller, Kravfras, Förklaring/Rational, Nöjdhetsvillkor, Rekommendation och Resursestimering.

FF-table.png

Själva förbättringsförslaget ligger under rubriken ”Vi rekommenderar” i tabellen,

men ett krav formuleras och förklaras (Rational)med ett bifogade nöjdhetsvillkor,

för att förbättringsförslaget ska bli tydligare.

För varje förbättringsförslag görs även en övergripande resursestimering.

Roll(er):

<involverade roller>

Kravfras:

<Kravfras formulerad enligt IREB-CPRE kravformat, som kravställer en funktion / tjänst som XX måste tillhandahålla>

Förklaring/Rational:

<förklaring av kravfrasen på ”pratigt format” med syfte att göra det tydligt varför kravfrasen skrivits överhuvud taget>

Nöjdhetsvillkor:

<om kravfrasen skulle realiseras hur vet vi att den är ”klar” och att det är tillräckligt bra gjort? Hur ser världen ut för att kravställaren ska vara nöjd? Vilka delar måste finnas med och vilken kvalitet ska lösningen ha?>

Vi rekommenderar:

<det vi rekommenderar att YY ska göra. Uteslutande intitiering av olika typer av projekt för att ytterligare bryta ner och specificera och realisera det formulerade kravet>

Resursestimering:

<antalet mantimmar och de externa resurser som vi estimerar att projektet behöver för att nå ett acceptabelt resultat>

”Det viktiga är inte att man SKRIVER krav eller HUR man dokumenterar

sina upptäckter, utan att man verkligen förstår VADman ska göra

innan man börjar ”spika, såga och måla”…

SPISEChjälper dig att ställa rätt frågor tidigt, innan allt fokus är

på detaljer i en lösning som man inte riktigt vet hur den valdes ut”

Denna BLOGGtext finns även på ett TÄNK!-format här

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravingenjörsskap och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.