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.
Trots att sagan är gammal (exakt uppgift saknas) och våra beställnings-, projektstyrnings- och leveransprocesser har förfinats sedan den skrevs händer det ändå att historien upprepar sig gång efter annan – i både stora och små projekt, i både offentlig och privat verksamhet – och vi verkar blir lika förvånade varje gång det sker.
Vilka effekter denna dåliga hantering har på de olika verksamheternas lönsamhet, utveckling, varumärke osv. kan vi bara spekulera kring…
För den som glömt bort sagan återges den här i en kort form.
Det var en gång en liten man som gick till skräddaren med ett stycke tyg. Han frågade skräddaren, som satt på bordet och sydde, om han kunde få en rock sydd av det lilla tyget.
- "Det går bra" svarade skräddaren och den lille mannen fick beskedet att rocken skulle bli färdig på lördag.
Den lille mannen tackade ödmjukt skräddaren och kom tillbaka på lördagen och frågade om rocken var färdig och fick till svar att "det bidde ingen rock".
- "Det bidde ett par byxor som blir färdiga nästa lördag". Varpå den lille mannen gick och kom tillbaka på lördagen för att få veta att "det bidde inget par byxor".
- "Det bidde en väst" och så fortsatte det lördag efter lördag. "Det bidde ingen väst", "Det bidde inga par vantar" för "Det bidde en tumme."
- "Jaså, bidde det en tumme"? sa den lille mannen. "Det var bra, mäster skräddare. Tack så mycket, mäster skräddare. Adjö, adjö, mäster skräddare."
Så tog den lille mannen sin tumme, gick sin väg och kom aldrig mer igen.
Varför?
Men varför är det så här, varför går det så illa och vad kan vi göra för att det ska bli bättre?
Det kan såklart finnas tusen och en anledningar till att det inte alltid blir som det var tänkt och när man tror att man hört alla bortförklaringar dyker det ofta upp en till.
I publikationen The CHAOS Report publicerar organisationen The Standish Group årligen statistik gällande utvecklingsprojekt och i en av de senaste rapporterna kan man bland annat läsa följande:
Man behöver inte vara alltför uppmärksam för att ganska snabbt kunna utläsa att det är två återkommande faktorer som påverkar både chanserna till framgång och riskerna för misslyckande – nämligen ”User Involvement” och ”Requirements”. Båda dessa faktorer är dessutom närliggande och graden av användarengagemang brukar kunna ha en avgörande betydelse för kvaliteten på kravställningen.
Misslyckanden brukar också medföra oönskade kostnader och konsekvenser, där kostnaderna brukar kunna räknas antingen i form av pengar eller i form av tid eller i värsta fall både och. Konsekvenserna av ett misslyckat projekt kan vara ännu fler och betydligt allvarligare. Lyckligtvis är det inte så ofta ett misslyckande resulterar i dödsfall – även om det händer ibland – men att man råkar skaffa sig missnöjda kunder och användare eller råkar försvaga sitt varumärke är inte helt ovanligt.
Oavsett vilken projekt- eller processmodell man valt att arbeta efter är det naturligtvis så att ju tidigare man gör rätt i projektet, desto bättre brukar det bli för projektekonomin och omvänt – det vill säga ju senare man upptäcker att ändringar måste göras, desto dyrare brukar det bli. Skenande förändringskostnader kan oftast mildras, eller till och med elimineras, genom att man tillämpar en iterativ utvecklingsprocess men om man jobbar i ett linjärt vattenfallsprojekt är det knappast ovanligt att kostnaderna rusar i höjden och det är inte heller ovanligt att de kan uppgå till tio gånger högre, eller mer, i projektets slutfas jämfört med i projektets början.
För den som vill läsa mer om misslyckade projekt från jordens alla hörn - och om vad dessa misslyckanden haft för kostnader och effekter - rekommenderas sidorna Why projects fail samt Catalogue of Catastrophe.
Vad göra?
Tillbaka till frågan: Vad kan vi göra för att förbättra situationen?
Baserat på ovanstående borde det nu vara ganska lätt att besvara frågan och lösningarna är såklart ”Investera i seriöst analysarbete – affärs-, risk- och kravanalys – både innan och under projektets gång” samt ”Arbeta iterativt”.
I de fall där det är svårt eller omöjligt att arbeta i en iterativ process, till exempel vid byggnationen av ett hus eller en bro eller vid framtagning av underlag för offentlig upphandling, blir således det initiala analysarbetet en ännu viktigare, om inte avgörande, faktor för framgång.
Hur göra?
Inkludera Modern kravhantering i alla utvecklingsprojekt – stora som små!
Med Modern kravhantering menar jag kravhantering där organisationers och användares behov sätts i centrum och där metoderna för kravhantering anpassas till den aktuella verksamheten.
Förutsättningar för att detta tillvägagångssätt ska ge önskat resultat och framgång är att analysarbetet inkluderas som en naturlig och tongivande del i utvecklingsprojektet och att analyserna görs både tidigt och kontinuerligt samt verksamhetsanpassat. För verksamheter där iterativa processer inte är möjliga, t.ex. husbyggen eller offentliga upphandlingar, är det ännu viktigare att analysarbetet görs tidigt.
Nedan finner du ett urval av tidigare inlägg på Kravbloggen som på ett eller annat sätt anknyter till ämnet i denna text:
http://kravbloggen.se/2018/01/17/nar-processer-och-metoder-krockar-med-verkligheten/
http://kravbloggen.se/2017/08/22/beskriv-dina-behov-och-inte-en-losning-snalla/
http://kravbloggen.se/2017/08/17/reflektioner-fran-almedalen-2017-fokus-upphandling/
http://kravbloggen.se/2017/05/04/experten-vs-kravhanteraren/
http://kravbloggen.se/2016/09/27/att-vara-iterativ-utan-att-vara-agil/
http://kravbloggen.se/2013/11/14/kravhantering-i-offentlig-upphandling/
