Kan vi göra något åt dåliga beställare av IT?

I våra uppdrag stöter vi ständigt på upplevelsen från IT-organisationer att deras kunder är dåliga beställare. Bristerna tar sig uttryck på två huvudsakliga sätt:

1. Beställningarna är otydliga.
2. Beställningarna kommer in/IT involveras alldeles för sent i processen.

Vad som är hönan och ägget i denna diskussion kan självklart diskuteras.

• Blandas IT in sent för att verksamheten gör fel eller för att IT inte säkerställt en tydlig dialog med sin kund som blickar framåt?
• Eller beror den på att IT alltid är sena med sina leveranser så de har inte tid att ta emot inflöde av beställningar eller är de alltid sena för att beställningarna alltid kommer in för sent?
• Är beställningarna otydliga eller är IT bara oinsatta i verksamhetsbehoven?
• Eller är beställningarna otydliga för att verksamheten inte förstår sina egna processer?

I denna blogg väljer jag att fokusera på otydliga beställningar och hur vi kan göra dem bättre.

Otydliga beslut och beställningar

Allt för ofta ser vi hur IT önskar att verksamheten fattar beslut/kravformulerar på helt fel nivå. Fokus läggs tyvärr ofta på val av teknik, plattform och tillverkare istället för att prata om vilka resultat som kunden vill uppnå.

Kunder till IT-organisationer nyttjar IT i första hand för att realisera ett eller flera verksamhetsmål. IT-lösningar och produkter används för att genera specifika resultat, som affärsverksamheten och kunden önskar uppnå.

Detta innebär att om IT-organisationen kan att utveckla förmågor till tjänsteleverans och ett fokus på just tjänster snarare än IT-komponenter kan dialogen förflyttas mot mer produktiva domäner. För detta måste vi dock först reda ut vad en tjänst är.

Till vårt stöd kan vi använda oss av ITILs definition på tjänst.

Service outcomes

Nyckelordet här är just ”Outcomes” eller resultat som vi skulle säga på svenska. Intressant nog är det också precis det som vi fokuserar på när vi pratar om mjukvaruutveckling enligt agila metodiker. Genom att använda det format som används i agila systemutvecklingsmetoder, User Stories,  som modell för våra krav kan vi fokusera på vilka resultat som kunden vill uppnå.

User stories

I en User Story definierar vi vilken (typ av) användare som vill kunna göra vad för att få vilket specifikt resultat/uppnå specifikt mål. Precis som på illustrationen ovan. 

Utgångspunkten är att först definiera vilken användartyp som har behovet (Roll). Därefter beskriver vi behovet (Feature eller funktion). Och slutligen förklarar vi varför eller till vilken nytta funktionen är (Benefit eller värde). 

Att vi tar oss tiden att förklara just nyttan ger mottagaren av behovet en mycket tydligare bild av kontext och därmed blir det lättare att identifiera vad som är bästa lösningen. Det går ju alltsom oftast att lösa ett behov på fler än ett sätt. 

”User stories” tillämpat utanför mjukvaruutveckling

Denna metod går även att använda även om vi inte specifikt jobbar med mjukvaruutveckling. Det kan till exempel tillämpas för införande av standardsystem, integrationer eller rena infrastrukturtjänster.

Det vi gör är att ändra på användare. Så istället för att skriva ”säljare” eller ”logistiker” eller vilken användare vi nu tidigare använt så kan vi bli mer svepande som ”användare” om vi talar om tex. klienttjänst eller ett applikationsnamn eller liknande för applikation till applikationstjänter.  

Självklart så kan vi upptäcka att vi på den nivån fortfarande saknar en mängd viktig information, specifikt när vi pratar om mer tekniskt orienterade användare som tex applikationsförvaltare. Därför kan vi behöva komplettera med sådant som portnummer, xml-filformat etc. men också viktigt är att få med information om kapacitetsmängder. Dvs hur mycket kommer vi att skicka över den nyöppnade porten så vi vet att vi inte överlastar. Komplettera därför tekniska User Stories med objekten Warranty eller garanti som vi skulle sagt på ITIL-språk (tillgänglighet, kapacitet, säkerhet och katastrofhantering). Länka gärna till detaljerna snarare än försöka klämma in det i excelen.

Som alltid så är det också viktigt att tillsammans med kunden utreda vad som är krav och vad som är önskemål. Detta kan noteras i User Storyn, alternativt genom att sortera upp i egna ark eller genom prioriteringskolumn. Den exakta lösningen är inte viktig och kan helt klart variera mellan olika organisationer.

Det fiffiga

Det fiffiga med att dokumentera på detta sätt är att det blir relativt enkelt att med kunden komma överens då vi hela tiden utgår från ett gemensamt data. Så dela detta med kunden, det finns utmärkta verktyg för detta som Sharepoint, Google Docs, Dropbox eller mer avancerade verktyg anpassade för mjukvaruutveckling i första hand.

Slutligen vill vi rekommendera att inte försöka lösa alla problem på en gång med alla kunder. Ta små steg av förbättringar, pröva er fram tillsammans med kund. Det som fungerar ska ni repetera, det som inte blir bra ska ni ändra på.

Så ta er tid till att reflektera kring och löpande förbättra era metoder och processer. Glöm bara inte bort att ni måste vara lojala mot vad ni kommit överens om, dvs faktiskt använda de verktyg, mallar och modeller ni sagt att ni ska använda. Det är alldeles för lätt att göra som vi alltid gör (oavsett resultat) för vi är alla vanemänniskor och det tar tid att utveckla och fästa nya rutiner.

Lycka till, och hör av er gärna med frågor eller resultat från egna User Stories.