<<åter

Dålig kunskap kvaddar stora projekt

(Lars Danielsson, ComputerSweden 2002)

Flera konsulter som Computer Sweden talat med ser bristen på kunskap om den dominerande utvecklingsmetoden Rup som ett problem. De stämmer också in i ett fördömande av stora projekt.

Rapporterna om stora misslyckade projekt har varit vanliga under senare år. Många av projekten har drivits av myndigheter och i ett flertal fall har Rationals utvecklingsmetod Rup använts, till exempel i RFVs projekt som dragit över budget med hundratals miljoner kronor.

- Det är inte fel på Rup, tvärtom, jag uppskattar verkligen Rup. Problemet är att det ibland drivs stora projekt där endast ett fåtal av de inblandade kan använda Rup, säger Oscar Nyströmer, projektledare på Arete.

Han säger vidare att det är viktigt är att alla kan den metod som används, samt att projekten drivs av erfarna projektledare. Dessutom anser han att stora projekt ofta blir svåra att överblicka.

Stort är farligt
Søren Ravnskov, vd på Astrakan strategisk utbildning, har lång erfarenhet både som utvecklare och projektledare. Han håller med Oscar Nyströmer.

- Ju större projekt, desto större risk att det misslyckas. Om projekt når en viss gräns vad gäller storlek misslyckas de alltid, säger Søren Ravnskov.

Inte heller han vill peka ut Rup som skurken i dramat. Han anser också att det är dålig kunskap om Rup som orsakar problem i projekt.

- Det finns inte så många duktiga Rup-konsulter. Det räcker inte med en certifiering.

Han säger vidare att det finns en övertro på metoder, vilket orsakar problem i projekt. Anders Torelm, vd på Rational i Sverige, håller med om att bristen på kompetens om Rup är ett problem.

- Vi försöker förändra situationen med böcker, utbildning och certifiering. Certifiering är inget kvitto i sig, men ett steg på vägen. Det krävs praktisk erfarenhet för att få certifiering, till exempel fem år för nå certifieringsnivån Principal Consultant

Han påpekar att ett av problemen är att det ibland brister i kunskapsöverföring från konsulter till företags egen personal. När ett projekt är klart försvinner konsulterna utan att ha överfört kunskap om Rup.

För stor kostym
Dan Johnsson som ansvarar för forskning och utveckling på Frobozz påpekar att Rup är extremt konfigurerbart, till exempel vad gäller mängden dokument som ska skapas under ett projekts gång. Det är svårt att hitta en balans mellan formalia och viktig information.

- Rup inbjuder till en för stor kostym. Många dokument kan ge en falsk känsla av trygghet. Dokument är bra, att prata är bättre, säger Dan Johnsson.

Han anser inte att en metod som Rup behövs i små projekt, med mellan 10 och 20 utvecklare. Däremot behövs en sådan kanske i ett projekt med mellan 100 och 200 utvecklare.

David Byers är vd för XP Tools som arbetar med utvecklingsmetoden extreme programming, xp. Denna metod brukar ibland beskrivas som rena motsatsen till Rup, men David Byers håller inte med.

- Rup är ett ramverk och det går antagligen att formulera xp som en instans av det ramverket. Det går att göra bort sig med både xp och Rup, säger han.

Standard-Rup eller inte?
Enligt David Byers är ett av problemen med Rup att det finns en övertro på metoden i dess standardutförande. Han anser att alla metoder, även lättviktsmetoder som xp, måste anpassas till de projekt och organisationer som de ska användas i.

Anders Torelm på Rational tycker inte att det är lika viktigt med anpassning av Rup.

- Det är däremot viktigt att välja vilka delar av Rup man ska använda och koncentrera sig på dem.

Ett vanligt problem med stora projekt är, enligt David Byers, att de inblandade inte vet vad de vill ha från början, att de har oklara mål som är orealistiska. Han påpekar att anledningen till att misslyckade projekt ofta drivs med tunga metoder helt enkelt är att lättviktsmetoderna inte har börjat användas i dessa sammanhang ännu.

- När lättviktsmetoderna blir accepterade tror jag att vi kommer att se misslyckanden med dem också. Det är först då som vi verkligen kan bedöma hur bra de fungerar.

* Kommentar - Det är konsulternas fel, (Conny Leinstedt, ComputerSweden 2002)

<<åter