Ersätt diffusa kvalitetsmål i projekt med tydliga egenskaper

Du har säkert sett det otaliga gånger i projektdirektiv, i projektplaner och på möten: Projektet ska leverera med hög kvalitet. Det låter bra. Ansvarsfullt. Professionellt. Men fråga projektledaren vad det innebär konkret. Fråga teamet hur de ska mäta det. Fråga beställaren eller styrgruppen när de är nöjda. Du kommer inte få ett tydligt svar från någon.

Kvalitet är inte ett mål – det är ett resultat av tydliga krav

I många organisationer används kvalitet som ett värdeord. Något man vill stå för, något som signalerar seriositet. Men i projekt räcker det inte att signalera utan projekt handlar om leveranser, och leveranser måste vara tydligt definierade.

Internationella standarder som till exempel ISO 9001 definierar kvalitet som graden i vilken krav uppfylls. Kvalitet är alltså ingen ambitionsnivå utan det är uppfyllda krav. Och om kraven är otydliga, blir kvaliteten också otydlig. En annan grundläggande tanke inom kvalitetssystem är att kvalitet inte kan byggas in i efterhand utan det är den kvalitativa processen i sig som ger det kvalitativa resultatet. Det räcker alltså inte att granska slutprodukten; kvaliteten måste vara inbyggd i hur arbetet bedrivs från start.

Ett exempel från verkligheten

En organisation startar ett projekt för att införa ett nytt ärendehanteringssystem. I projektplanen formuleras det kort: Systemet ska hålla hög kvalitet, vara lätt att anpassa och ha en hög användarvänlighet. Systemet ska också upplevas som modernt. Just de här formuleringarna användes också i upphandlingsunderlaget som skickades ut till tänkbara leverantörer. Låt oss spola framåt i projektet. Det är nu dags för acceptanstester och slutligt godkännande.

Projektgruppen anser sig ha levererat en lösning som fungerar tekniskt och uppfyller de förväntade funktionerna. Verksamheten tycker inte att systemet är tillräckligt användarvänligt. IT hävdar att kraven är uppfyllda och att systemet är enkelt att anpassa för den som är expert. Styrgruppen förväntade sig en mer modern känsla och ett snyggare gränssnitt och vill att leverantören tar ett större ansvar för att rätta till upplevda brister. Leverantören anser sig ha levererat enligt överenskommet avtal.

Hur hamnade projektet här egentligen? Ingen har egentligen fel – problemet är att kvalitet aldrig översattes till konkreta egenskaper. Om projektet istället från start till exempel hade definierat att registrering av ett ärende ska kräva max tre klick, att svarstiden vid normal belastning ska understiga två sekunder, att 95 procent av testanvändarna ska klara de centrala momenten utan instruktion och att anpassningar ska gå att göra utan teknisk kompetens – då hade kvaliteten blivit mätbar. Diskussionen hade handlat om fakta, inte om subjektiva upplevelser och tyckande.

Rätt kvalitet – inte högsta möjliga

Projekt har alltid begränsningar: tid, budget och förväntat resultat. Inom de ramarna är målet inte att nå högsta möjliga kvalitet utan rätt kvalitet. Det vill säga den nivå som faktiskt behövs för att uppfylla beställarens effektmål.

Ett projekt som levererar mer än vad som krävs kan låta generöst. Men i praktiken är det ofta ett tecken på otydliga prioriteringar och resursslöseri. Professionell projektledning handlar om att leverera exakt vad som behövs, varken mer eller mindre. Lösningar som går att verifiera, som är rimliga i förhållande till kostnad och tid, och som faktiskt skapar den effekt beställaren efterfrågar.

Balansen mellan projektmål (vad projektet ska leverera) och effektmål (vad resultatet ska åstadkomma) är avgörande. När den balansen är tydlig från start blir kvalitetsfrågan enkel: levererar vi det som krävs för att effektmålen ska nås?

Därför arbetar vi inte med abstrakta kvalitetsmål

På ProjektStegen förespråkar vi ett praktiskt angreppssätt. Istället för övergripande och svepande kvalitetsmål arbetar vi med att tydliggöra alla krav och egenskaper i leveranserna. Det innebär att varje leverans ska ha en tydlig beskrivning, definierade egenskaper, mätbara målvärden, godkännandekriterier och en utsedd person som ska godkänna varje leverans. Dessutom ska rutinen för hur godkännande ska gå till i praktiken vara definierad. Genom det här arbetssättet behövs inga svepande formuleringar om hög kvalitet utan det finns redan inbyggt i strukturen och arbetssättet.

Struktur skapar förutsägbar kvalitet

Vi möter ofta organisationer som säger att de vill höja kvaliteten i sina projekt. Men vägen dit går sällan via ökad ambition. Den går via mer tydlighet. När kraven är konkret formulerade, gemensamt förankrade, dokumenterade och uppföljningsbara minskar risken för missförstånd, omarbete och konflikter vid godkännande. Det är egentligen inte mer komplicerat än så – men skiftet i synsätt är avgörande. Här gäller det att projektledaren är stark i början av projektet och verkligen ser till så att projektet får en tydlig och robust bas att utgå ifrån och inte lockas med av argument som att det där löser vi sen, det viktigaste är att vi kommer igång snabbt.

Sammanfattningsvis kan sägas att det handlar om att gå ifrån retoriken Projektet ska leverera med hög kvalitet till strukturen Vi definierar exakt vilka egenskaper leveransen ska ha och hur vi ska kontrollera och godkänna varje leverans.

Buy quality, cry once

Det finns ett gammalt engelskt ordspråk som lyder: Buy quality, cry once. Tanken är enkel: köper du något billigt och dåligt gråter du varje gång det strular, går sönder eller måste ersättas. Köper du rätt från början gråter du kanske en gång över allt arbete och tid som behöver läggas ner i början för att definera behov och krav, men belöningen kommer senare.

Samma logik gäller i projekt. Att ta sig tid att definiera krav och egenskaper ordentligt i början kan kännas omständligt och tidskrävande. Men priset för att hoppa över det steget betalas alltid senare i form av omarbete, konflikter och leveranser som ingen riktigt är nöjd med. Den initiala investeringen i tydlighet är nästan alltid billigare än kostnaden för otydligheten. Det här arbetssättet gör att projekt verkligen levererar med hög kvalitet, inte för att någon skrev någon elegant formulering i ett projektdirektiv, utan för att alla från start visste exakt vad det betydde.