Att leda ett IT-projekt är som att jonglera med gelébollar – varken enkelt eller prydligt. Informationstekniken är extra stökig eftersom den ständigt är i rörelse. Den förändras, anpassas och hotar hela tiden att förändra verksamheten som den ser ut idag.

Traditionell projektledning, som den används i byggprojekt ­eller tillverkningsindustri, rör sig kring fasta och mätbara element. Men IT-projektledning blir mer komplicerad, inte minst på grund av förändrade verksamhetsbehov och krävande beställare.

Eftersom bra IT-projektledning är så svårt har vi sammanställt en lista med vanliga frågor och svar för att försöka förklara hur viktigt det är – och göra projektledningen enklare att bemästra.

Vilka är de grundläggande principerna för IT-projektledning?
 Projektformen är ett kortsiktigt försök att skapa en unik produkt, tjänst eller miljö. Det kan handla om att göra sig av med gamla servrar, utveckla en egen e-handelssajt eller slå ihop databaser.

Alla projekt slåss mot tre begränsningar: tid, kostnad och omfattning. För att ett projekt ska lyckas måste dessa tre begränsningar (projektledningens tredubblade svårigheter) balanseras mot varandra. Om någon av de tre får mer utrymme än de andra är projektet på väg mot katastrof.
Alla projekt, oavsett om de handlar om IT eller inte, går igenom fem faser som kräver projektledning: inledning, planering, genomförande, övervakning, kontroll och avslutning. Varje fas innehåller processer som tar projektet från idé till införande.

Varför misslyckas IT-projekt så ofta?
 Enligt Standish Group, som gör mätningar av hur stor andel
IT-projekt som lyckas respektive misslyckas, var det bara 29 procent av de IT-projekt som genomfördes 2004 som lyckades. Siffran är nedslående.

Att IT-projekt misslyckas så ofta beror för det första på att de är svårare än andra. I den här typen av projekt ingår alla de vanliga utmaningarna, som deadlines, begränsad budget och för få människor som kan lägga tid på projektet. Men de stöter också på specifika tekniska utmaningar i form av hårdvaru-, operativsystems-. nätverks- eller databasproblem, säkerhetsrisker och interoperabilitet, samt de förändringar av hårdvara och mjukvara som kommer från tillverkarna.
För det andra misslyckas IT-projekt ofta redan från början – inte i slutet – på grund av bristande planering. IT-avdelningen måste tänka igenom vilka resurser som måste avsättas för ett projekt, vilka färdigheter som behövs och vilka människor som ska involveras, samt göra en realistisk bedömning av hur lång tid det kommer att ta att utveckla, testa och implementera projektresultatet. Annars kommer projektet bara att bli en enda röra varpå det blir omöjligt att avsluta projektet i tid, klara budget eller få med de funktioner som ska ingå – det vill säga de tre faktorer som generellt avgör om ett projekt lyckas eller inte.

För det tredje misslyckas IT-projekt på grund av brådska. Eftersom så många företag idag är beroende av IT för att skaffa sig konkurrensfördelar, hastar de igenom utvecklingssatsningar och införande av system för att vara först på marknaden med nya IT-baserade produkter, tjänster och kompetenser. För att behålla sin konkurrenskraft känner företagen ofta att de måste skära i kostnaderna samtidigt som de bibehåller sin produktionsnivå. Det sätter i sin tur press på stora, kostsamma projekt, som införande av övergripande affärssystem eller plattformsuppgradering.

Ett projekt med otillräcklig planering, riskbedömning och testning är dömt att misslyckas från start.

Slutligen misslyckas IT-projekt för att de är för storskaliga. Ett omfattande projekt har större chanser att lyckas om det bryts ner i ett antal mindre, mer lätthanterliga projekt. Ett projekt som ska konvertera företagets hela historik, transaktioner och blanketter till en digital databas som ska finnas tillgänglig online kan exempelvis vara otroligt svårt och tidskrävande. Att dela upp arbetet i en serie mindre projekt gör det hela mer lätthanterligt. I detta fall kan man tänka sig följande gång: först konverteras de befintliga posterna till digitalt format, sedan genomförs ett andra projekt för att få igång databasen internt, följt av ett tredje projekt för att få ut databasen på webben.
Sådana små projekt kan avslutas efter varandra och man får större flexibilitet än med ett stort, komplicerat och svårhanterligt projekt.

Hur avgör man om ett projekt kommer att misslyckas när det redan har inletts?
I projektets startfas måste man bestämma kriterierna för vad som kan anses lyckat respektive misslyckat. Till exempel, för att anses lyckat måste projektet uppfylla vissa kvalitetskrav (som Six Sigma eller ISO), hålla sig inom en viss budget, klara en deadline och/eller leverera en bestämd funktionalitet.
Ett annat sätt är att använda en måttstock, eller ett mätetal, ­exempelvis 15-15-regeln. Den innebär att om ett projekt är mer än 15 procent över budget eller 15 procent över tidsramarna, kommer det förmodligen aldrig att hämta igen den tid som förlorats eller tjäna in de kostnader som krävs för att det ska lyckas.

Det finns också en del projektstyrningstekniker som kan användas för att avgöra om ett projekt kommer att lyckas eller misslyckas. Till exempel intjänat värde, som låter företaget mäta förändringar i tidsplanen och när projektet ska avslutas, och skapa index för tidsplaner och produktionskostnader. Det kan även användas för uppskattning av förmodat avslutningsdatum och hur ekonomin påverkas när projektet är klart. Om man, med detta sätt att mäta, ser att projektet kommer att kosta så mycket att det kommer att innebära en förlust det kvartalet, så vet man att det är misslyckat. Fler varningssignaler finns i artikeln ”Att döda ett företagsprojekt”.

När bör ett projekt avbrytas?
 IT-projekt avbryts av flera olika anledningar, men oftast handlar det om dålig planering. Andra orsaker kan vara att man överskrider kostnaderna med mer än 15 procent, förseningar av de viktigaste delarna och undermålig kvalitet.
För att avgöra om ett projekt bör avbrytas bör man redan vid starten ställa upp kriterier som anger när projektet ska avblåsas. Man kan exempelvis fundera på gränser för förseningar och överskridande av budget, eller förändringar av förutsättningarna för verksamheten. Om företaget råkar ut för en signifikant eller varaktig nedgång av omsättningen, oavsett av vilken anledning, kanske man ska överväga att avbryta projektet för att spara pengar. Likaså om projektet har vuxit eller förändrats så mycket från grundförutsättningarna att det har blivit något helt annat.

Om det verkar besvärligt att lägga ner projektet, kanske man vill skapa mindre projekt för att försöka tillgodogöra sig en del av de kostnader man lagt ner. Trots allt har små projekt större chans att lyckas än stora.

Kan man försäkra sig om att projekten lyckas?
 Företagen borde skapa eller använda någon form av standard för projektledning. Ledningen kan snabbt avgöra vilka projekt som går bra och vilka som inte gör det om alla projekt har samma tillvägagångssätt och använder samma mått för prestationer. En standard för projektledning innebär gemensamma grundregler och förväntningar på projektgruppen. Det ger också projektledare, arbetsledare och personal ett gemensamt språk för projektledning som underlättar kommunikation och ser till att alla förstår varandra.
Att använda en blandning av olika projektledningstekniker gör det omöjligt för företaget att mäta projektens framgångar. Och om man inte kan mäta hur projekten går, så kan man inte heller avgöra vilka processer och metoder som fungerar och vilka som behöver förbättras.

Vilka projektledningsmetoder finns det, och vilka fungerar bäst för olika IT-projekt?
 Det finns tre ledande metoder för IT-projektledning. Den första är baserad på traditionell projektledning och fungerar för alla IT-projekt oavsett vilken teknik som de handlar om och hur länge projektet ska hålla på.
Den andra metoden kallas extrem programmering, ibland förkortat till XP (inte att förväxlas med operativsystemet). Extrem programmering är projektledning som är speciellt utformad för mjukvaruprojekt. I XP används en modell för programutveckling som involverar användare, kunder och programmerare i fyra faser: kodning, planering, design och test.

Den tredje metoden för IT-projektledning kallas Scrum. Den har fått sitt namn från ett rugbylag och använder också olika steg som planering, kodning, genomförande och test av programvara. Scrum har en egen terminologi och fasta regler kring möten, delmål och hur länge olika planeringsfaser ska vara.

Vissa företag har speciella grupper avdelade för projektledning. Vad sysslar de med och bör alla ha en sådan avdelning?
 De företag som har egna projektledningsgrupper, har skapat dem för att centralisera och samordna all projektledning, inklusive IT, på hela företaget. Projektledningsgruppen bestämmer grundreglerna för och förväntningar på projekten som helhet, men även för projektledarna, arbetsgrupper och andra intressenter

Projektledningsgruppen samlar ihop önskemål om förändringar av projektens omfattning och ser till att projektledare och arbetsgrupp får sådant som utbildning, projektledningsprogram, planeringsmallar och blanketter som kan göra att projekten löper smidigare. Projektledningsgruppen prioriterar vilka projekt som ska genomföras och när det ska ske. De avgör också vilka resurser som ska läggas på olika projekt för att förhindra att olika avdelningar kommer ihop sig om resursanvändningen.

En väl fungerande projektledningsgrupp leds ofta av en erfaren projektledare och har personal som kan stötta och hjälpa de olika projektledarna i arbetet (med mötesprotokoll, samordning av projektinformation samt kommunikation och möten med uppdragsgivare). Projektledningsgruppen kan finnas inom eller utanför IT-avdelningen. Vissa företag vill ha en överordnad projektledningsgrupp för alla projekt (oavsett om de handlar om IT, utveckling eller produktlanseringar) som är oberoende av de andra avdelningarna. Projektledare brukar vanligen rapportera till projektledningsgruppen. En del projektledare kan ingå i gruppen, medan andra inte gör det, speciellt om de tilldelats rollen som projektledare för ett speciellt projekt och egentligen har andra arbetsuppgifter förutom sin projektledarroll.

Nackdelen med en projektledningsgrupp är att den kan utgöra ett hinder för projektledarnas egna metoder för ledarskap och kontroll, genom att gruppen bestämmer vilka metoder projektledarna ska använda och får dem att följa specifika (och inte sällan tidsödande) metoder för att dokumentera sitt arbete.

Hur mycket ska projektledaren få bestämma?
 Projektledarna måste få avgöra vilka resurser de behöver för att uppnå en lyckad avslutning av ett projekt. Projektledaren behöver mandat att fatta beslut om hur stor personalstyrka och vilka processer och metoder som krävs för att projektet ska lyckas, annars står han eller hon helt maktlös. Men å andra sidan vill man inte ge ineffektiva projektledare för stort ansvar.

Generellt sett gäller att ju större projektledarerfarenhet man har, desto större självständighet och ansvar kan man förvänta sig att få. Maktstrukturen inom företaget anger ofta hur stort ansvar projektledare får, men det varierar givetvis mellan olika företag.

Vilka typer av certifieringar finns tillgängliga för projektledare och hur viktiga är de?
 Betydelsen av certifiering är fortfarande öppen för diskussion. Å ena sidan, betyder inte en certifiering att man är en bra projektledare. Å andra sidan har den som är certifierad och letar efter projektledarjobb en fördel framför den som inte har det. Certifiering visar att man har dokumenterad och bevisad erfarenhet av projektledning.

I USA finns ett antal ledande certifieringar för projektledare. Bland dem kan nämnas PMP, som står för Project Management Professional, CAPM, Certified Associate in Project Management och IPMA, International Project Management Association, samt Comptia Project+.
PMP-certifikat utfärdas av amerikanska Project Management Institute, PMI och kräver att projektledarna ska dokumentera sin projektledarerfarenhet och vilka resultat projekten har uppnått, samt ha intyg på att de har erfarenhet som utbildare. Dokumentationen bedöms av PMI:s representanter. För att få PMP-certifikatet måste man dessutom klara ett fyra timmar långt examensprov med 200 frågor.

CAPM-certifikat utfärdas också av PMI och är till för projektledare som inte har så lång erfarenhet som krävs för PMP. För att få CAPM-certfiering måste man också dokumentera projektledar­erfarenhet, utbildning och handledning i sin ansökan.

IPMA-certifiering är, precis som PMP, till för erfarna projektledare, men Comptias Project+ (samma företag har även olika typer av IT-certifieringar) vänder sig snarare till dem som tänker arbeta som projektledare för större projekt i framtiden. För att bli Project+-certifierad måste man få 499 poäng eller mer på ett prov med 80 frågor på 90 minuter. Project+ har inte samma förkunskapskrav som de andra certifieringarna.

Vår verksamhet utvecklas snabbt, men våra projekt verkar gå långsammare. Vad kan vi göra för att snabba upp våra projekt?
 Snabbt och långsamt är subjektiva begrepp, vad som verkar långsamt hos ett företag kanske är supersnabbt någon annanstans. Det är viktigt att bestämma vad som är en rimlig tidsram för att klara av ett IT-projekt, baserat på projektets omfattning, vad det ska resultera i och utifrån vilka ramar projektet har. Fundera på det, och avgör sedan om projekten verkligen är så långsamma. Finns det historik över tidigare projekt som kan jämföras med de pågående eller har projekten alltid tagit lika lång tid?

För det andra bör man fråga sig om projekten styrs av insatser eller om de har en fastställd varaktighet. Projekt som styrs av insatser kan snabbas upp om de får mer resurser för att de ska klaras av på kortare tid, vilket dock innebär ökade kostnader.

Om projektet ska utföras under fastställd tid, som vid exempelvis test av en mjukvara i två månader innan den släpps, så finns det inte mycket man kan göra för att minska den tiden utan att öka riskerna.

Regelverk, lagstiftning och standarder är vanliga inom vår bransch, men hur påverkar de våra IT-projekt?
 Projekt som måste rätta sig efter lagstiftning och regelverk kräver mer direkt planering. Till exempel kan det kräva att man måste göra mer utförlig dokumentation när man utvecklar företagstillämpningar eller inför ett nytt produktionssystem. Projektledare bör gå igenom vilka regelverk som måste följas i just deras bransch, det kan gälla allt från tillverkning till hälsovård.

Om projektet måste följa vissa regelverk resulterar det i mer arbete, och när man tar med det i beräkningen kan det även öka projektets omfattning och dess kostnader.

Vi vill skicka våra projektledare på utbildning. Vad bör de få ut av det och hur vet vi att en viss utbildning är värd besväret?
 För att få utdelning på en investering i utbildning bör man först bestämma vad projektledarna ska ha lärt sig efter utbildningen. Utvärdera projekten och se efter var problemen finns.

Har projekten misslyckats med planering, schemaläggning, genomförande eller kommunikation? Alltihop? Genom att avgöra var projekten behöver hjälp, kan en projektledarutbildning innebära att projektledarna kan leverera bättre projekt.

Det finns en hel del kurser att välja mellan på marknaden, men en utbildning som är anpassad till företaget gör att man kan få en egen lösning som är mer fokuserad på de områden som behöver förbättras. På så vis kan man strunta i de områden som projektledarna redan är bra på.