Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter
Store it-projekter er kritiske højrisiko investeringer, der kan koste jobbet for selv den øverste topledelse og i værste fald sænke en hel organisation.
Det kan derfor undre, at så uforholdsmæssigt mange it-projekter får lov til at gå over tid og budget.
Vi har set det med projekter som Ejendomsvurderinger, Proask, Amanda, Digital Tinglysning, Rejsekortet, Polsag og mange andre i både den offentlige og private sektor.
Vi er nu et sted, hvor nervøsiteten for store it-projekter helt afholder nogle organisationer fra at udvikle nye kernesystemer og fra at opdatere kritisk it-infrastruktur.
Foruden at hæmme udvikling, åbner det op for mere kompleksitet og dermed flere fejlkilder, men også for flere sikkerhedshuller.
Ja, det er nærmest blevet en naturlov, at store it-projekter går over tid og budget. Men hvad er det, vi mangler i vores ligning, når ellers dygtige og erfarne projektledere så ofte rammer forkert?
Hvis du på engelsk googler “it project estimate”, vil du ende med et uendeligt udvalg af metoder og modeller, billeder og skabeloner.
Det skorter ej heller på tommelfingerregler og rådgivning om, hvad it-projektledere skal præsentere for ledelsen.
For eksempel, at projektlederen først skal foretage et skøn, som dernæst fordobles, da estimatet alligevel vil være forkert.
Et andet forslag er en analogi, som andre afdelinger i organisationen vil forstå - eksempelvis at det nogle gange tager længere tid at køre på arbejde afhængigt af trafiksituationen. Et tredje råd lyder, slet ikke at give et estimat.
Der findes værktøjer
Der findes dog værktøjer, der kan hjælpe os hen mod professionalisme - og væk fra gætterierne.
En velkendt metode er function points, hvor man som navnet antyder, ved hjælp af funktionspunktsanalyse måler størrelsen på et system baseret på dets funktionaliteter ved at måle antallet af input, output, forespørgsler samt interne og eksterne filer.
Det giver et objektivt syn på applikationens størrelse og kompleksitet samt en meget præcis forståelse af opgavens omfang.
Men denne metode mangler en faktor, der alt for ofte bliver overset i it-branchen; nemlig mennesker. Én ting er opgavens omfang - men hvad med styrken på den organisation, som skal udvikle og implementere løsningen?
Softwareudvikling er meget afhængig af dine it-udvikleres dygtighed og erfaring. Som eksempel kan man forestille sig en hjertetransplantation, der kun kan udføres af dygtige og erfarne hjertekirurger.
Tilføjelse af en eller flere almindeligt praktiserende læger til teamet vil ikke hjælpe patienten eller højne succesraten for operationen.
Det vil sandsynligvis blot besværliggøre arbejdet for hjertespecialisten, der også bliver nødt til at beskæftige sig med uerfarne læger under arbejdet. Headcount har altså ingen bestemmende succesværdi.
Samme variant
Den samme variation kan findes blandt it-udviklere. Blot at tildele mange hoveder vil ikke føre projektet i mål, medmindre de pågældende udviklere har de nødvendige færdigheder og erfaring.
Snarere tværtimod - vi ser faktisk, at jo flere hoveder, der fedter rundt imellem hinanden, jo vanskeligere bliver det at være produktiv.
Ligesom læger er it-udviklere ikke udskiftelige stik. Imidlertid tager mange modeller og skabeloner til projektestimater ikke den menneskelige faktor med i ligningen - og hvis de gør, er det ofte i form af meget grove, tæt på meningsløse skalaer.
Menneskers præstationsniveau er den vigtigste faktor, når man måler sine performance drivers, og tager man disse med i ligningen, vil man være langt bedre rustet til at foretage realistiske projektestimater.
Det korte svar på, hvorfor så mange projekter sprænger deadline og budget er altså, at man i hovedsagen ikke er dygtig nok til at kende størrelsen på den færdige applikation samt styrken på den implementerende organisation.
Har man derimod et retvisende billede af opgavens omfang og en god bedømmelse af sin organisatoriske styrke, har man også et godt udgangspunkt for beregning af leverance og pris for et projekt.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.