Endast 35 % av alla IT-projekt når framgång.*

Företaget ville dra nytta av sin välkända varumärkesportfölj online och lansera en ny bäst i klassen-portal som skulle svepa konkurrenterna av mattan och generera hög vinst.

Time to market var nyckeln, men budgeten var också mycket viktig. I deras fleråriga roadmap skulle det under första året lanseras e-handel för resor, vin, kläder, ved och musik.

Den två månader långa förstudien startade och teamet försökte få grepp om projektmål, omfattning, arkitektur, organisation och bemanning för att driva portalen när den lanserades.

Allt eftersom tid och budget fastställdes måste projektets framgång noggrant kontrolleras. En gemensam scope-matris fanns på plats för att hålla ordning på vad som skulle designas och byggas för de olika webbplatserna.

Under projektet inspirerades man av att titta på ”det bästa av det bästa” och lade till hundratals user stories varje vecka. Snart var man uppe i över tvåtusen och projectscopet hade inte slutat växa.

Det fanns inget annat alternativ än att gå tillbaka till projektsponsorn med önskemål om mer tid och budget för att kunna leverera en portal som skulle matcha den höga ambitionen.

Efter flera diskussioner och förhandlingsrundor beslutade kunden att avbryta projektet helt. Det orsakade stor besvikelse i projektteamet eftersom de flesta av dem hade gått med i företaget för att förverkliga en vision de trodde på.

För att undvika fallgropen:

• Diskutera och kom överens om vad som är viktigast av tid, kostnad och omfattning. Det är omöjligt att alla tre är lika viktiga eftersom det kommer att driva fel beslut och prioriteringar. Att säga att kostnaden inte är viktig betyder inte att kostnaden kan vara oändlig!
• Kom överens om ett business case för projektet och matcha ambitionsnivån för att möjliggöra en uppsida.
• Använd en MVP-metod för att kunna realisera tidigt affärsvärde på resan mot att bli bäst i klassen.

Det är rätt leverans!

Projektet bestod av många delprojekt och involverade över hundra personer på olika avdelningar inom företaget och dess tio underleverantörer.

Som vanligt skedde regelbundna styrgruppsmöten med statusrapportering, demos, heta diskussioner, riskbedömningar, ändringsbeslut med mera.

Ämnet som ständigt väckte många frågor var färgen på delprojektens trafikljusstatus (RAG):

• ”Hur kan du rapportera grönt, när vårt projekt är rött och är helt beroende av din leverans?”
• ”Du var röd förra veckan och nu är du plötsligt grön, men ingenting förändrades egentligen?”
• ”Varför rapporterar du vecka efter vecka gult även när det är veckovisa förändringar?”

Det här orsakade mycket frustration för projektsponsorn som inte kunde lita på vad som sas på mötet och var tvungen att gissa vad den verkliga statusen var när kritiska beslut skulle fattas.

Ungefär halvvägs in i projektet fick statusrapporteringen en stor vändning när en ny programledare klev in och ändrade hur styrgruppens möten sköttes.

För att undvika fallgropen:

• Skapa tidigt tydliga definitioner för vad RAG-status (röd, gul, grön) betyder för ett specifikt projekt. Det är ofta inte samma definition på olika företag, och ibland inte ens samma vid olika projekt inom ett företag.
• Lägg den tid som krävs för att se till att alla projektledare är bekväma med att rapportera den verkliga RAG-statusen för sitt delprojekt eftersom viktiga beslut är beroende av det.
• Kom överens om vilka åtgärder som måste vidtas för att kursen korrigeras vid rapportering av gult eller rött. Projektledaren bör kunna svara på nyckelfrågan: ”Vad behöver vi göra för att komma tillbaka till grönt?”

Det är rätt leverans!

Under planeringen för MVP-releasen ombads åtta kunder att prioritera 400 funktioner i fyra kategorier. Efter den första omgången som varade i två timmar, landade 392 av funktionerna i kategorin ”affärskritiskt”.

Efter den andra omgången som varade i ytterligare fyra timmar hade sex funktioner flyttats ner till kategorin ”viktigt”. Inte utan mycket heta diskussioner inklusive fult språk och livliga gestikulationer.

I slutändan måste affärskritiskt delas in i fyra underkategorier som en kompromiss och för att tillgodose en rimlig 80/20-strategi för en MVP-lansering.

Men när testningen började blev det ännu värre. Nästan alla loggade defekter klassificerades som prioritet ett. Det spelade ingen roll om det var ett stavfel eller en sökning som inte fungerade.

För att undvika fallgropen:

• Få alla intressenter ombord med MVP-metoden – en tidigare release med den viktigaste funktionaliteten gör det lättare för användare att påverka framtida releaser.
• Ge tydliga definitioner av vad de olika kategorierna för prioritering av scope representerar och hur de knyter an till affärsvärdet. Detta gäller även för defektprioritering.
• Kom överens om tydliga roller i teamet för att stödja både scope- och defektprioriteringsprocesser.

Det är rätt leverans!

Företaget valde en standardprogramvara för sin nya e-handelsplattform och ville maximera användningen av standardprocesser och -funktioner med minimala anpassningar. Resultatet blev annorlunda då verksamheten inte var öppen för att ändra sitt arbetssätt och riskera att göra konsumenterna besvikna.

Till slut lades hundratals anpassningar till, lanseringen försenades och den totala kostnaden för den nya e-handelslösningen översteg budgeten rejält. För att inte tala om den framtida kostnaden för att underhålla alla specialanpassningar.

För att undvika fallgropen:

• Få alla intressenter ombord med designmetoden – att implementera standardprogramvara innebär också att anpassa sig till standardprocesser.
• Hantera förväntningarna tidigt och låt verksamhetsanvändarna prova de inbyggda funktionerna i standardprogramvaran.
• Motivera anpassningar utifrån verkligt affärsvärde i stället för subjektiva perspektiv som ”så här har vi alltid gjort det”.
• Säkra ett starkt ledningsstöd för alla förändringar av befintliga processer och system – utan det kommer ingen att förespråka resultatet.

Det är rätt leverans!

Time to market var nyckeln i projektet. Tanken var att man skulle lista ut hur prestandatestningen skulle genomföras längs vägen, och förlita sig på den funktionella testmiljön för prestandatestningen.

Under projektet låg allt fokus på utveckling och ingen tid ägnades åt att definiera prestandakriterier eller dimensionera testmiljön och ladda testdata.

När det närmade sig lanseringen var det dags för prestandatestning, men eftersom prestandamiljön inte var redo beslutade projektägaren att helt enkelt hoppa över det. Man hoppades på att den funktionella testfasen var tillräckligt bra för att belasta systemet tillräckligt och gav grönt ljus för lansering.

Projektet lanserades i tid, men i takt med att fler kunder anslöt till tjänsten slutade de erbjudna tjänsterna att fungera periodvis. Teamet arbetade dygnet runt för att hålla tjänsterna vid liv och felsökte samtidigt prestandaproblemet. Hotfixar lades till i realtid innan utrullningen stoppades och sattes på paus tills en korrekt lösning var på plats.

För att undvika fallgropen:

• Definiera tydliga prestandakriterier och skapa plats för prestandatestning innan lansering.
• Se till att prestandamiljön har rätt hårdvara, mjukvara och testdata.
• Använd prestandatänk i utvecklingen och genomför prestandatestning som en del av sprintarna.

Det är rätt leverans!