Hur svårt kan det egentligen vara att höja kvaliteten i IT-projekt?

av | apr 24, 2016 | ITIL/ITSM, LEAN IT

Kvalitet inom IT-leveranser och IT-projekt är A och O.  Men upplevs ofta ändå som svårt kanske också därför att kvalitet är svårdefinierat. Ofta används definitionen  ”vad kunden vill ha”, eller ”möter förväntningar”. Självklart kan vi definiera kvalitet som en funktion som på något sätt möter kundens förväntningar. Och i regel förväntar sig kunden att leveranser ska ske inom tid, innehålla det som överenskommits samt fungera redan vid leveransen. Allt för att möta kundens kvalitetskrav. Men alltför ofta så misslyckas IT-organisationer. Även om agila metoder onekligen har inneburit stora förbättringar för mjukvaruutvecklingen så täcker det dock inte in alla delar av IT-tjänsteleveransen.

Inom produktionsindustrin har man länge arbetat med frågan om kvalitet i produktion. Ramverk och metoder som Lean, Six Sigma och Total Quality Management har inneburit stora förbättringar för många organisationer. Men hur gör organisationer för att implementera dessa verktyg eller ramverk i sina verksamheter? Och när vi tänker Total Quality, måste det bli mastadont eller går det att börja i det lilla?

PDCA

Att identifiera endast en person som haft störst instrumentell påverkan på kvalitetsarbetet runt om i världen är kanske svårt men ett vanligt förekommande namn är Deming, grundaren av PDCA-hjulet. När man första gången bekantar sig med hjulet verkar det dessvärre vara bedrägligt lätt. Det är väl rimligt att vi först planerar (Plan), därefter utför (Do) och sedan kontrollerar resultatet (Check) och vid behov korrigerar (Act)? Vad är det som är så magiskt med detta egentligen?

Men som det mesta som är genialiskt, kan en enklare yta lätt dölja finesser som finns däri. Disciplinerat PDCA-arbete, såsom agila sprintar eller Toyotas adaption av PDCA-hjulet är därför värt att igen repetera och analysera.

PLAN

I Plan-fasen görs det kanske allra viktigaste arbetet som oftast missas av organisationer som skall jobba med en förbättring, åtgärda något problem eller på annat sätt utveckla sin organisation. I Plan-fasen kommer vi först och främst att definiera vilket problem vi vill lösa. En bra problembeskrivning är inte nödvändigtvis svår men nyckeln till framgång är att inte falla i den bedrägliga fällan att på en gång beskriva en lösning. Resultatet av det blir ofta att vi åtgärdar symptom men lyckas aldrig åtgärda själva sjukdomen eller den underliggande orsaken till problemet. Inom Toyota Production System och Lean använder vi oss metoden av att fråga oss fem varför för att veta att vi inte fastnar för tidigt i analysen.

Toyotas 5 varför

Toyota använder sig av en metod de kallar 5 Why. Enkelt beskrivet kan det sägas att man som en nyfiken 5-åring inte nöjer sig med svaret på första frågan utan då frågar vidare enligt devisen ”varför är det så” och så vidare. Allt i syfte att hitta det underliggande felet samt identifiera vad som är orsak och verkan i problemställningen. Här är ett bra exempel på en praktisk tillämpning hittar ni här

Därefter kommer vi att behöva analysera problemet, dess troliga eller tänkbara orsaker, testa våra hypoteser för att förstå vad som är orsak och verkan samt slutligen definiera vad vi bedömer som den eller de viktigaste eller mest sannolika rot-orsaken till det problem vi definierat.

Kom ihåg!

  1. Fokusera på problembeskrivningen
  2. Validera orsakssambanden
  3. Skilj på problem och konsekvenser
  4. Var grundlig

DO

I Do-fasen blir vårt viktigaste jobb att nu testa de hypoteser vi formulerat i Plan-fasens problemanalys. Test görs genom att pilotera, formulera och skapa proof-of-concepts samt på annat sätt verifiera och genomföra det vi önskar förbättra i en kontrollerad miljö. Detta hjälper oss att se att vi får de önskade resultaten samt att det i efterhand går att korrigera riktning samt validera data mot vår hypotes. I stor utsträckning är detta ett datadrivet område men framför allt faktabaserat och inte upplevelsebaserat.

I agil-metodik använder vi oss av principen korta iterationer för att skapa objekt som går att förevisa för kunden för att få snabb feedback på om den nya funktionen löser de problem som kunden önskar åtgärda/förbättra. (Samtidigt som vi bygger vidare på den empiriska processteorin som Agile och Scrum vilar på genom löpande mätning och uppföljning av nedlagd arbetstid, burndown, sprint velocity och estimation precision).

Kom ihåg!

  1. Testa dina hypoteser ordentligt
  2. Använd kvantitativa mätmetoder

Presterar vår lösning enligt kundens önskemål, och framför allt presterar vi på de områden och leveranser som kunden efterfrågar? 

CHECK

I Check-fasen kontrollerar vi om vår hypotes/er stämmer, vi bedömer resultatet av pilotförsök, vi utvärderar Sprint Demo tillsammans med kund för att få tidig feedback och en möjlighet att korrigera eller åtgärda riktning, innehåll, kvalitet etc. Inom ITIL:s Change-process motsvaras detta av testprocessen då vi tidigt testar av funktioner i testdriven utveckling samt där vi genomför slut-tester innan produktionssättning för att veta att vi inte implementerar nya fel eller buggar i IT-miljön.

I den agila metodiken använder vi oss av konceptet Sprint Demo, tester (manuella och automatiserade) såväl som A och B-tester för att pröva hypotesen att leverans av ny funktion är den efterfrågade/mest önskade, dvs löser kundens problem.

Först när vi är säkra på att vi förstått problemet och säkerställt att vi hittat en lösning för det så implementerar vi det i full skala. 

Kom ihåg!

  1. Involvera kunden
  2. Lyssna och få feedback
  3. Justera

ACT

Och därmed har vi kvar det sista steget vilket antingen är att starta om hjulet (givet att vi inte fick önskade resultat i Check-fasen) alternativt helt enkelt implementera den lösning på problemet som vi tagit fram. Om däremot resultatet var positivt kan det istället många gånger handla om att göra en ”ramp-up” dvs gå från piltogrupp till stor deploy eller marknadsföring mot bredare marknad och nya kunder.

Kom ihåg!

  1. Våga börja om processen vid behov.
  2. Annars rulla ut och skala up.

I praktiken är många ITIL-processer såväl som den agila metodiken Scrum uppbyggd enligt dessa PDCA-principer. Dessvärre misslyckas många med sina implementationer då de inte haft full förståelse för hur PDCA-hjulet egentligen fungerar. Genom att aktivt arbeta med PDCA-processen kan IT-organisationer föra in mer kvalité i sina dagliga leveranser.

Det vanligaste misstaget som jag stött på i företags kvalitetsprocesser är att de hastar igenom fasen för problemanalys och för tidigt fokuserar på lösningsalternativ. Resultaten har därmed uteblivit och många gånger har man bara skapat nya problem istället.

Exemplen på de som lyckas genom att följa PDCA-tänket i den form som Deming avsåg kan fungera som både inspiration och vägledning i ert förbättringsarbete av verksamheten.

Förbättringar som också kommer ge ekonomiska resultat. Eller vad sägs om Toyotas 55-åriga period av vinst (med ett undantag). GE:s fantastiska vinst och tillväxt under Jack Welch som var en pionjär inom Total Quality Management på sin tid. Eller varför inte Steve Jobs som var maniskt inriktad på att hans produkter skulle ha en perfekt kvalitet och vars bolag det ju gått ganska bra för de senaste åren.

ITIL/ITSM
Agile Governance
Service Value System

Service Value System

I detta inlägg, som är del 2 i en serie inlägg om ITIL4,  beskriver vi ITILs Service Value System.  För att Service Management ska fungera ordentligt måste det fungera som ett helt och integrerat system. ITIL:s Service Value System (SVS) beskriver hur alla de olika...

Share This