Utvecklingsprojekt

Då och då poppar de upp. Artiklar om misslyckade utvecklingsprojekt. Journalister gräver fram projekten som aldrig kommer i mål och skrotas när de beslutande tvingas inse misslyckandet. Enorma belopp går förlorade. Storsatsningar visar sig vara illusioner. Några utvecklingsprojekt av jätteformat har jag inte deltagit i med det har blivit många mindre arbeten med varierande utfall. I dagens fundering vill jag lyfta fram tre områden med fallgropar.

Först har vi något jag vill kalla överorganisering. Snäva tidshorisonter medför att fler personer tillförs projektgruppen. Med på köpet kommer också ökad tid för att administrera och hålla ihop projektet. Tid som ofta växer exponentiellt med antalet som ingår i projektet. I utvecklingsprojekt finns också tendenser att bemanna med personer som inte är direkt inblandad i utvecklingsarbetet. Orsaken kan vara allt från att “belägga lediga resurser” till att skapa hierarkiska strukturer. Resultatet blir vad jag vill kalla ett bakgrundsbrus. Projektet drar inte bara på sig extra tid eller “waste” i Lean-termer det skapar också interna störmoment.

Avgränsningar är svårt. Det är betydligt lättare att lägga till extra funktionalitet än att ta bort funktioner. Ofta hörs uttrycket “bra att ha funktioner”. De ska säljas in. Vänder vi på resonemanget och rangordnar funktionerna efter bidrag till verksamheten blir något annat synligt. Funktioner som kommer långt ner i listan blir tveksamma. Ska de verkligen genomföras. Hur utfaller jämförelsen mellan kostnaden och vad som tillförs?

Jag har tagit med denna ofta visade bild för att illustrerar kommunikationsproblematiken som förekommer inom utvecklingsprojekt. Även om vi förutsätter att alla inblandade har samma modersmål så talas olika språk. Verksamheten har sitt språk medan utvecklarsidan har en helt annan terminologi. Hur överbryggas språkförbistringen?

Beställarsidan kan till synes kringgå problematiken med att endast göra affärer med de som använder välbekant terminologi. Enligt min mening är det en tveksam strategi. När ett utvecklingsprojekt upphandlas är kunnande inom utvecklingsområdet det viktiga. Verksamhetskunnande är den specialitet som beställaren har inom sina egna väggar. Med denna hantering av problematiken pratas visserligen samma språk men skapas någon användbar programvara?

Leverantörssidan kan också försöka hantera kommunikationssvårigheterna med tillsättande av “the man in the middle”. En person som ska överbryggar språksvårigheterna och sköta all kommunikation mellan kunden/beställaren och utvecklingsteamet. Funktionen kombineras ofta med beslutsrätt. Min erfarenhet från denna strategi är att den ofta skapar mer problem än den löser. En extra nivå tillförs som filtrerar kommunikationen. Risken är uppenbar att viktig information går förlorad. Information som är av stor betydelse i utvecklingsarbetet. Andra negativa effekter är hierarkiska prestigelåsningar som hämmar arbetet. Funktionen blir också ofta en flaskhals i projektarbetet.

Det finns inga genvägar. Vad som behövs är en öppen dialog mellan kund/användare och utvecklare. Om utvecklingsteamet ska göra ett bra jobb måste de förstå problematiken i verksamheten. Endast genom en förutsättningslös dialog med användarsidan uppnås denna förståelse. Funktionalitet kan byggas på en mängd olika sätt. Hur hittar man fram till det enkla? Hur kan utvecklarsidan hålla fast vid enkelheten det vill säga bygga mindre när motsatta tankegångar gör sig påminda. Bygga mer och bygga komplicerat.