Vad styr val av metodik för design och utveckling av digitala system?

’Smidigt’ eller ’agilt’ har varit ett buzzword de senaste åren när man pratar metodik för design och utveckling av digitala system. Lite tillspetsat handlar smidiga metoder alltid om att kunna anpassa kurs och prioriteringar utifrån vad som ger det mest omedelbara värdet. Metoden ställs ofta mot konventionell flerstegsmetodik; en fasinriktning med betoning på grundlig planering inför utveckling. Det du fruktar som uppdragsgivare är självklart att du känner att du betalar detsamma, men får mindre.

Vi påstår dock att större projekt faktiskt är avhängiga av smidig utveckling för att lyckas. Både ekonomiskt och kvalitetsmässigt. Som regel kommer det du trodde, då ni engagerade en konsult som skulle utvärdera vad ni behövde, garanterat vara något annat när projektet levereras. Knowits perspektiv på större projekt är ofta att en mer kontinuerlig process, där designen utvecklas i samspel mellan designernas lösningsförslag och kundens krav och kriterier, ger bättre och mer relevanta lösningar. Målet med smidige projekt är att minska förluster.

Fördelarna är att man snabbare kan komma ut på marknaden, lära och anpassa sig under tiden utifrån insikten att det man trodde för ett år sedan inte behöver vara så smart i år. Detta blir mer och mer aktuellt när vi ser hur snabbt digitaliseringen förändrar samhället. Företaget förändras – men allra viktigast är att kundernas preferenser hela tiden ändrar sig och måttstocken är som regel global. 

Hur ska ni kunna välja rätt anbud utan flerstegsmetodik?

Man lägger mycket tid på att beräkna för att kunna ge en exakt kostnadsbild, och projekten väljs mycket utifrån det pris som en leverantör har. Helt enkelt för att ni självklart vill ha kontroll över framtida kostnader. Normen idag är alltför ofta att enorma resurser används för att utforma, uppskatta och utveckla krav som så småningom ändras eller avvisas efter testning. Vi tror inte att man alltid kan förvänta sig att det är en framgångsfaktor att binda sig eller den andra parten till en fast uppskattning av ett komplicerat projekt. Vi påstår att det inte alltid ger kontroll – utan bara en illusion av kontroll.

Flerstegsmetoden bottnar i klassiska ingenjörsprojekt. Digitaliseringsprojekt har en annan karaktär än konventionella IT-projekt och kräver olika metoder än konventionellt IT-tänkande. Ni kan få ut mer av er utvecklingsbudget genom att omfördela resurserna för att utnyttja den oundvikliga förändring som kommer att inträffa under projektet.

Varför ska du avstå från flerstegsmetoden?

Som beställare måste du vara involverad annars slipper du aldrig undan flerstegsmetoden . I konventionella it-projekt är det svårt att ändra på något. Tydliga ritningar på allt som ska göras och allt planerat i minsta detalj före första spadtaget. Slutet är definierat redan före starten. För att lyckas med goda digitaliseringsprojekt krävs flexibilitet av båda parter när projekten når en viss storlek.

Kraven förändras med tid och erfarenhet

Kraven en organisation har i början är inte nödvändigtvis det man önskar i slutändan. Dessa är vanligtvis uppställda baserat på den erfarenhet man hade vid den tiden. Nya system, portaler, användargränssnitt eller andra digitala ytor ger nya upplevelser som i sin tur ger nya idéer. Ett projekt är klart först när ingen använder det längre. Inte tidigare, men man brukar tycka att man är klar när man levererat produkten. Vi anser att ett utvecklingsprojekt behöver bearbetas tills det inte längre ska användas. Med andra ord, det finns alltid mer att göra.

Många bäckar små, blir en stor Å

Smidig arbetsmetodik börjar med en vision om ett större mål, innan man sätter ihop små ”paket” med utveckling som det är mer sannolikt att man lyckas med. Färre saker kan gå snett och man har kontroll när det sker. Man färdigställer mindre bitar, testar dem och går vidare till nästa. Är det en nätbutik ni är ute efter, eller är ni egentligen ute efter att öka omsättningen? Även om visionen är styrverktyget vet vi av erfarenhet att detta kan förändras under projektets gång. Om ett projekt ska bli framgångsrikt måste det täcka det faktiska behovet, bäckarna måste få rinna som det är naturligt för dem, inte dit vi bestämde att de skulle gå när vi började planera.