När börjar ett projekt sjunka?
Varje IT-projekt börjar på samma sätt. Det finns ambitiösa planer, en tidsplan, presentation av de första mockups och övertygelsen om att företaget om några månader kommer att använda ett modernt system. Inledningsvis ser allt lovande ut, men med tiden kommer de första förseningarna. Deadlinen skjuts fram en vecka, senare en månad. Antalet buggar ökar, kommunikationen med leverantören blir allt svårare och svaren låter allt oftare: "En liten stund till", "Det är bara en mindre fix" eller "Vi är redan i mål."
Vid en viss tidpunkt visar det sig att företaget istället för en färdig produkt har ett ofullbordat projekt som ingen vill ta över.
Det är ett scenario som är mycket vanligare än man kanske tror.
Det största problemet är inte koden
De flesta entreprenörer antar att om projektet inte fungerar så beror det på dåligt skriven kod. Visst – ibland är det just så. I praktiken ligger problemet dock ofta djupare.
Det saknas dokumentation. Arkitekturen har vuxit fram "på löpande band". Det finns inga automatiska tester. Integrationer har gjorts provisoriskt. Nya funktioner har lagts till utan analys av deras påverkan på hela systemet. Som ett resultat orsakar även små ändringar nya fel.
Det är lite som att renovera ett hus utan ritningar. Varje rum kanske kan färdigställas, men efter hand visar det sig att väggarna inte står där de borde, installationerna är dragna slumpmässigt och ombyggnaden blir allt dyrare.
När är det dags att säga "stopp"?
Ett av de svåraste ögonblicken för en företagsägare är beslutet att avbryta samarbetet med den nuvarande leverantören. Många entreprenörer dröjer för länge med detta beslut.
Varför?
För att projektet redan har kostat mycket pengar.
För att det känns som slöseri med tid.
För att man tänker "det kanske fortfarande kan lyckas".
Inom psykologin kallas detta för förlorade kostnader. Ju mer vi redan investerat, desto svårare är det att erkänna att den nuvarande riktningen leder ingenstans.
Ibland är dock det bästa beslutet inte att fortsätta ösa pengar i samma problem, utan att stoppa projektet och lugnt analysera situationen.
Kan varje projekt räddas?
Nej. – Och det är viktigt att säga det ärligt.
Det finns projekt vars reparation skulle kosta mer än att bygga dem från grunden. Ibland är teknologin redan föråldrad eller arkitekturen utformad på ett sätt som omöjliggör fortsatt utveckling.
Därför bör det första steget aldrig vara att ge löften.
Det första steget bör vara en revision (audit).
Först efter noggrann analys av koden, dokumentationen, infrastrukturen och processerna kan man svara på om det är mer lönsamt att reparera den befintliga lösningen eller att starta om med ett nytt projekt.
En bra teknologipartner kommer inte att säga det som kunden vill höra.
Den kommer att säga det som är bäst ur ett affärsperspektiv.
Hur ser det ut i praktiken att rädda ett projekt?
Mot förmodan börjar det inte med programmering.
Först måste man förstå vad man har att göra med.
Vi analyserar systemets arkitektur, kodens kvalitet, kommunikationen mellan moduler, datasäkerhet, prestanda och möjligheter till vidareutveckling. Vi kontrollerar dokumentation, ändringshistorik och använda teknologier. Ofta vet man redan efter några dagar var det verkliga problemet ligger.
Först då utarbetas en handlingsplan.
Ibland räcker det att städa upp koden och förbättra några nyckelkomponenter. Andra gånger krävs en ombyggnad av utvalda moduler. Ibland är den mest rimliga lösningen att skapa ett nytt system och återanvända det som redan gjorts.
Det finns inga två identiska projekt.
Precis som det inte finns en enda recept för att rädda dem.
Varför är det svårare att ta över ett projekt än att bygga ett nytt?
Det är en fråga vi ofta får från kunder.
Svaret är enkelt.
När vi bygger ett system från början känner vi varje designbeslut. Vi vet varför en viss lösning valdes och vilka antaganden som gjordes.
När vi tar över ett annat projekt måste vi först återskapa den kunskapen.
Det är lite som att ta över byggandet av ett hus efter ett team som lämnat byggplatsen utan ritningar, utan dokumentation och utan information om vad som faktiskt har gjorts.
Därför kräver projektåterställning inte bara programmeringskunskap utan också erfarenhet av arkitektur, analys och design.
En teknologipartner bör finnas vid din sida även när problem uppstår
Ett bra software house kännetecknas inte av hur det inleder ett projekt.
Det kännetecknas av hur det reagerar när svårigheter uppstår.
Man kan inte förutse allt. Affärskrav, teknologier och användarnas behov förändras. Det viktiga är om teamet kan hitta lösningar, kommunicera risker tydligt och tillsammans med kunden fatta de bästa besluten.
Det är då förtroendet byggs.
Hur arbetar vi på Web24?
Vi närmar oss projekt som kräver övertagande med stor försiktighet.
Vi ger inga löften efter det första samtalet.
Först analyserar vi situationen. Vi kontrollerar vad som har gjorts, vad som kan återanvändas och vad som behöver byggas om. Först därefter förbereder vi en rekommendation och en plan för vidare åtgärder.
Vårt mål är inte att skriva ytterligare tusentals rader kod.
Vårt mål är att föra projektet till den punkt där det faktiskt börjar stödja affärsutvecklingen.
Sammanfattning
Om ditt projekt sitter fast, leverantören slutat svara, tidsplanen bara existerar i teorin och varje fix skapar nya buggar, betyder det inte nödvändigtvis att allt är förlorat.
I många fall går problemet att lösa.
Men man måste börja med ett steg – en grundlig analys av situationen.
För innan man börjar rädda ett projekt är det värt att först ta reda på varför det började sjunka.
