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?

gungan

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.

This entry was posted in Programmering. Bookmark the permalink.

One Response to Utvecklingsprojekt

  1. Lon W. Cobb says:

    Att ta utgångspunkt i kundens efterfrågan, eftersträva 100%-ig kvalitet, arbeta på ett standardiserat sätt och driva ständiga förbättringar är något som det flesta företag och organisationer idag prioriterar. Många kallar det lean andra har valt att kalla det något annat. De flesta har börjat med lean i produktionen för att eliminera det som inte skapar kundvärde som: överproduktion, väntetider, transporter, onödiga rörelser, felaktiga processer, lager och defekter. Resultaten har blivit synliga och inspirerat allt fler att även införa lean i administrationen. Tanken här är den samma, att eliminera det som inte skapar kundvärde. För tjänstemännen i administrationen eller som jag föredrar att kalla dem kunskapsarbetarna är tillgång till korrekt information vid rätt tillfälle hårdvaluta. Kunskapsarbetaren är idag allt mindre beroende av pappersbaserad information. För de flesta är det elektronisk information som ska hanteras i diverse IT applikationer. Informationsflöden som ofta rör sig blixtsnabbt över intranet och Internet. Det betyder att de källor till slöseri man finner i fabriken inte alltid har sin motsvarighet i administrationen. Exempel på ytterligare källor som skapar slöserier i administrationen är: onödiga e-mail, onödiga processer och onödig komplexitet, onödig rapportering, onödig tidsspillan, hanterande av för många parallella aktiviteter och projekt samtidigt samt en för hög arbetsbelastning. Att låta lean teamet från fabriken leda införandet av lean i administrationen är inte alltid lyckat då de lean-verktyg som fungerade i fabriken inte alltid räcker till. Tvärtom, att införa 5S för ökad ordning och reda på kontoret leder ofta till att kunskapsarbetaren anser att lean-insatsen inte är något för dem, efter att han har tröttnat på att sorterat gem och tejpa upp var saxen och häftmaskinen ska ligga för att alla lätt ska kunna hitta den.

Comments are closed.