Ska projektet aldrig bli klart? Medan de som väntar på resultatet blir allt mer otåliga så svettas projektledare och programmerare utan att komma framåt snabbt nog.

Vår amerikanska systersajt CIO.coms kolumnist Peter Wayner pekar ut ett antal orsaker till att mjukvaruprojekt nästan alltid tar längre tid än man beräknat. Kanske förklarar de inte alla förseningar men kan ändå ge insikt i vart allt hårt arbete i projekten tar vägen.

Här är några av de orsakerna:

Förutsättningarna förändras

Visst, projektet kanske har samma namn som när det drogs igång för flera månader sedan – men sedan dess har förutsättningarna för både omfattning och leverans förändrats så det kunde lika gärna ha bytt namn.

Kanske är det övergripande målet detsamma men någon har ändrat arkitekturen så pass mycket att allt måste göras om från början.

Egentligen kanske det inte ens är rättvist att påstå att projektet tar längre tid än planerat – det är snarare ett helt nytt projekt fast det inte fått samma uppmärksamhet när det drog igång som det första.

Kanske har rentav en del andra projekt blivit klara under de där månaderna vilket kan förklara att utvecklarna har

Diskussioner och överläggningar

Trots att många utvecklare knorrar om öppna kontor och talar om behovet av avskildhet och enorma hörselkåpor för att kunna koda så räcker tiden ändå inte till för alla de samtal som krävs för mjukvarudesign. Att diskutera metoder känns nästan lika viktigt som att bli klara med arbetet.

Vi kan skämta om all tid som läggs på möten kring hur en meny ska struktureras eller hur ett schema ska utformas men även de enklaste projekt kräver att vi bygger något ganska nytt.

Att koda är inte som att bygga en väg. Att optimera mjukvara tar längre tid för det har inte gjorts oräkneliga gånger sedan romartiden och definitivt inte med de krav som affärsstöttande system behöver.

Agilt har sina begränsningar

För chefer är processen allt. Så när det gäller att hålla tidsramen så tittar en chef på ramverk och metoder. De som leder mjukvaruprojekt vill gärna diskutera den bästa utvecklingsmetoden – men sanningen är att alla har sina begränsningar.

Ramverk är trots allt bara riktlinjer och praktiskt arbete skiljer sig från arbete i teorin. Undantag måste hanteras även när projektklockan tickar.

Utvecklare brukar hålla sig till agilt för att få så mycket frihet som möjligt att kunna välja var de vill bidra – men utan ledning kan det resultera i kaos.

Rörligt mål

Ofta kan mjukvaruutvecklare inte överhuvudtaget kontrollera hur deras arbete får framåt eftersom de arbetar mot rörliga mål. Kunder och aktörer inom verksamheten kommer hela tiden med förändringar och nya önskemål.

Att lägga till något nytt kan vara lätt – men ibland är det komplicerat och förstör en del av det arbete som gjorts tidigare.

Designgranskning en tidstjuv

Samtidigt som det är en viktig del av utvecklingsprocessen så vill alla att mjukvaran ska göra mer och älskar att lägga till önskemål när designen ska granskas.

Ibland är det omöjligt att säga nej till önskemål trots att de ligger uppenbart utanför projektets ramar.

Dessutom kan sådant som låter som blygsamma förfrågningar kräva mycket omkodning. Och ibland kan det ta flera timmar av kodgranskning bara för att förstå om det är enkelt eller svårt.

Med det sagt så är granskning tillsammans med de andra aktörerna nödvändigt. Det är en del av en god utvecklingsprocess. Så vi är dömda att fortsätta snurra runt kring koden och försöka besluta oss för vad som ska läggas till och vad som kan lämnas till version 2.0 – eller 5.0.

Långsamt är bättre

Projekt som går långsamt kan driva en galen. Men att mjukvaruutveckling har samma natur som en sengångare är inte en bugg – det är en funktion.

Att rusa igenom viktigt arbete gör att det garanterat blir fullt av fel. När kodare tar tid på sig så är det för att lägga en solid grund och se till att logiken är välgranskad och grundlig.

Och att klaga på att det går för långsamt tar fokus från de bestämda steg som ska tas och gör att projektet blir mer riskfyllt. Det bästa är att bara jobba på.