Innehåll

• Certifiering steg för steg
1. Certifieringskrav
2. Skapa ett PMI-konto
3. Ansök om examineringsrätt
4. Boka examen
5. Studera
6. Studietips
7. Ta examen
8. Underhåll certifieringen
• Project Management Body of Knowledge
1. Project Management Framework
2. Project Life Cycle Definition
3. Project Management Processes
• Rita Mulcahy's PMP Exam Prep
1. Tricks of the Trade
2. Project Management Framework
3. Project Management Processes
4. Integration Management
5. Scope Management
6. Time Management
7. Cost Management
8. Quality Management
9. Human Resource Management
10. Communications Management
11. Risk Management
12. Procurement Management
13. Professional and Social Responsibility

Jag har nyligen anträtt den långa vägen mot projektledarcertifieringen PMP (Project Management Professional). Eftersom certifieringen inte bygger på memorering (inte så mycket i alla fall) utan på omsättning av teori i praktik har jag tänkt knyta samman kurslitteraturen med mina egna erfarenheter. Om jag samtidigt kan inspirera dig till att bli projektledare och bidra till din certifiering så är det bara en bonus.

Certifiering steg för steg

Certifieringskrav

För en certifiering som Project Management Professional krävs följande:

• Utbildning: Högskoleexamen eller gymnasieexamen
• Projektledarerfarenhet: 3 år och 4 500 timmar (5 år och 7 500 timmar om du har gymnasieexamen)
• Projektledarutbildning: 35 timmar

Se PMP Credentials Handbook för detaljer.

Skapa ett PMI-konto

Om du uppfyller certifieringskraven så behöver du först skapa ett webbkonto hos Project Management Institute (PMI). Det gör du på PMI.org Registration. Webbkontot är gratis men du kan också bli medlem hos PMI för i skrivande stund $129. Medlemskapet ger dig diverse medlemsförmåner såsom tillgång till artiklar och e-böcker.

Ansök om examineringsrätt

Med ditt webbkonto loggar du in och ansöker om att få certifiera dig på PMP Registration. Där behöver du intyga att du uppfyller kraven enligt följande:

• Kontaktuppgifter: Namn, hemadress, jobbadress etc.
• Utbildning: Examensnivå, examensår, skola, adress, studieinriktning etc.
• Projektledarerfarenhet: Projekt, roll, datum, timmar fördelat på projektfas (Initiating, Planning, Executing, Controlling och Closing), arbetsbeskrivning samt kontaktuppgifter till överordnad
• Projektledarutbildning: Utbildning, företag, datum, timmar etc.

När du är klar kommer du att få en bekräftelse från PMI och det tar sedan ett par dagar för din ansökan att behandlas. Om du godkänns får du ytterligare instruktioner om hur du betalar och bokar examen. Du har ett år på dig från detta datum att skriva examen.

Boka examen

För att kunna boka examen måste du först logga in på ditt webbkonto hos Project Management Institute (PMI) och betala avgiften (i skrivande stund $555). Du får då ett PMI Eligibility ID som du använder när du bokar examen hos Prometric. BOKA I GOD TID, när jag bokade var det tre månaders väntetid (!).

Studera

För att studera till examen rekommenderas följande böcker. De uppdateras regelbundet så var noga med att studera de allra senaste utgåvorna.

• A Guide to the Project Management Body of Knowledge (PMBOK): PMI:s "skelett" som listar formella standarder och riktlinjer
• Rita Mulcahy's PMP Exam Prep: En bok som ger "kött" till PMBOK genom att förklara hur teorierna ska appliceras samt ge tips på hur man ska klara examen

Den förra boken är ganska tung och tråkig men ändå nödvändig som referenskälla. Den senare boken däremot är riktigt bra och underhållande att läsa. Jag kommer att sammanfatta innehållet och komplettera med mina reflektioner nedan. Observera dock att jag inte på något sätt vill ersätta dessa böcker - för att klara examen måste du läsa båda från pärm till pärm, helst flera gånger.

Studietips

Böckerna ovan innehåller sammanlagt nästan tusen sidor. Hur ska man ta till sig ett sådant överväldigande material? Under mina studier har jag funnit följande tips särskilt värdefulla:

• Memorera INTE: Att försöka memorera all information är inte bara en oöverstiglig uppgift utan gör också studierna tråkiga. Vissa undantag finns, såsom planeringsaktiviteter i rätt ordning och kostnadsformler, men de är väl utmärkta i PMP Exam Prep. Frågorna testar heller inte din förmåga att minnas teorin utan din förmåga att använda dem i olika scenarier.
• Förstå: Acceptera inte blint det du lär dig utan försök verkligen förstå. Du kommer då att kunna svara på många frågor med logik snarare än att rabbla ur minnet.
• Visualisera: Överför det du lär dig till din egen verklighet och fundera på hur du använder/borde använda teorierna. De blir då lättare att komma ihåg och studierna blir roligare.
• Tänk projekt: Projektledaren arbetar för projektmålet, varken mer eller mindre. Dolda agendor är naturligtvis tabu men också "extra" leveranser som inte ingår i projektmålen.
• Tänk stort: Frågorna förutsätter att du arbetar på ett stort projekt. Om du är van vid mindre projekt måste du alltså överföra dina erfarenheter till större sammanhang.
• Tänk perfekt värld: Frågorna förutsätter att ditt projekt är lett enligt teorin. Om du till en exempel får en fråga om ett problem under projektets utförandefas kan du anta att det finns en plan för att hantera det från projektets planeringsfas.
• Tänk brett (men inte djupt): Projektledaren är inblandad i alla delar av projektet men överlåter detaljer åt projektmedlemmarna.
• Tänk risker (inte status): Risker och möjligheter som kan påverka projektmålen identifieras och utvärderas under hela projektet av alla projektmedlemmar. Risker är därför i fokus under möten, inte status (som bäst kommuniceras på annat sätt).
• Tänk proaktivt: Projektledaren löser inte problem, han eller hon har redan förutsett dem och söker aktivt förebygga dem.
• Tänk matris: Frågorna förutsätter ofta att du arbetar i en matrisorganisation där projektledaren måste arbeta med funktionella chefer med de för- och nackdelar detta kan medföra.
• Tänk amerikanskt: PMI har amerikanska rötter och det kan lysa igenom i vissa frågor. Till exempel kan kulturella risker behöva hanteras genom formella "isbrytaraktiviteter" medan vi i Sverige snarare skulle hantera det genom informella fikastunder.
• Tänk ansvar: Projektledaren är ansvarig för projektets framgång, ingen annan. Om projektet inte är genomförbart ska projektledaren över huvud taget inte låta det börja.

Slutligen några tips för att bland flera RÄTTA alternativ hitta det BÄSTA av dem:

• Situation: Förstå situationen - det som är bäst i en situation är inte nödvändigtvis bäst i en annan
• Process I: Förstå processen - ett svar som är rätt i början av ett projekt kan vara helt fel i slutet av detsamma
• Process II: Förstå föregående och efterföljande aktiviteter - förutsätt att du har tillgång till leverabler från tidigare processer, såsom WBS
• Problem: Lös det viktigaste problemet först - välj alternativ som mest omedelbara problem, störst negativa effekt, grundorsak och proaktiva lösningar

Ta examen

Certifieringsexamen för PMP skrivs hos PMI:s lokala partner (i mitt fall Aktiviteten i Kista). Examen består av 200 flervalsfrågor online och varar i fyra timmar. Inga hjälpmedel är tillåtna. Det är dock möjligt att markera frågor man är osäker på och navigera fram och tillbaka mellan frågorna. Före själva examen kan man ta en liten online-utbildning om hur examensverktyget fungerar.

De som har skrivit examen tidigare rekommenderar att man förbereder sig både fysiskt och mentalt. Ta med mat och dryck om du behöver det, planera in raster och kontrollera tiden. Om du fastnar på en fråga så är det bättre att gå vidare. Ibland ger formuleringen av senare frågor ledtrådar till tidigare.

Vad själva frågorna beträffar så är bara ett alternativ rätt. De är ofta formulerade så att flera alternativ verkar rätt och du måste då välja det bästa alternativet. Se studietips ovan på hur du hittar det bästa alternativet.

Underhåll certifieringen

Tro inte att du är klar bara för att du klarade certifieringsexamen - din certifiering måste underhållas också. Det gör du genom att delta PMI:s Continuing Certification Requirements (CCR) Program under treåriga cykler:

• Identifiera start- och slutdatum för aktuell CCR-cykel
• Förvärva minst 60 Professional Development Units (PDUs)
• Bygg vidare på din projektledarutbildning (PMI, annat företag eller självstudier)
• Ge tillbaka till professionen (skriv artikel, arbeta som volontär eller arbeta som projektledare)
• Rapportera dina PDUs i PMI:s CCR system
• Ansök om förnyelse av certifieringen i PMI:s CCR system
• Bekräfta att du följer PMI:s etiska riktlinjer
• Bekräfta PMI:s förnyelseavtal
• Betala förnyelseavgiften (i skrivande stund $60 för medlemmar och $150 för icke-medlemmar)

Du får då ett nytt certifieringsbevis med uppdaterade cykeldatum. Mer om programmet kan du läsa i PMP Handbook

Project Management Body of Knowledge (PMBOK)

Mina intryck av the Project Management Body of Knowledge baserar sig på den tredje utgåvan.

1. Project Management Framework

PMBOK definierar projekt och projektledning enligt följande:

• Projekt:
• Temporärt: Projektet har en definitiv början och ett definitivt slut
• Unik leverabel: Projektet levererar en unik leverabel (produkt, tjänst eller resultat) och är alltså inte en del av en löpande verksamhet
• Progressiv utveckling: Projektet utvecklas inkrementellt, det vill säga det kan börja med ett övergripande mål som sedan specificeras under projektets gång
• Projektledning:
• Identifiera krav
• Etablera tydliga och nåbara mål
• Balansera krav på kvalitet, scope, tid och kostnader
• Anpassa planer och specifikationer till intressenters förväntningar

Låt oss stanna upp ett tag. Låter detta rimligt? Troligen. Låter detta som du jobbar idag? Troligen inte.

Som testledare arbetar jag ju i projektets slutfas och hjälper ofta till i förvaltningen också till dess att kunden är redo att ta över. Jag arbetar därmed i brytpunkten mellan en erfaren projektorganisation med inarbetade processer och en oerfaren förvaltningsorganisation som fortfarande försöker anpassa sig till de nya processerna. Hur ofta har jag inte velat att projektet fortsätter till dess att kunden är helt redo?

Men någon gång måste ju projektet ta slut och förvaltningen ta vid. Visst kan jag förstå användarnas frustration - i projektet kan fel ha rättats på en dag men i förvaltningen kan samma fel ta flera veckor att rättas. Men projektet är ju antagligen bara ett av många projekt och dess mål har prioriterats i konkurrens med andra mål. Att inte avsluta projektet när målen är uppfyllda vore att rasera inte bara projektets plan utan hela den strategi som ligger till grund för planen.

Det är därför bättre att avsluta ett projekt när dess mål är uppfyllda och, vid behov, initiera ett nytt projekt för att hantera eventuella problem.

PMBOK fortsätter med att definiera fem expertområden för projektledning:

• The Project Body Management of Knowledge:
• Project Life Cycle
• Project Management Process Groups
• Knowledge Areas
• Applikationsområde, standarder och regleringar
• Funktioner (produktion, marknadsföring, logistik, personal etc.)
• Teknik (IT-utveckling, tillverkande industri etc.)
• Specialisering (offentlig upphandling, produktutveckling etc.)
• Bransch (industri, jordbruk, finansiella tjänster etc.)
• Projektmiljö
• Kulturell och social miljö (intressenters egenskaper, såsom ekonomiska, demografiska och utbildningsmässiga)
• Internationell och politisk miljö (lagar, tidsskillnader etc.)
• Fysisk miljö (ekologi, geografi etc.)
• Generella färdigheter (redovisning, juridik, strategi, organisationsteori etc.)
• Interpersonella färdigheter (kommunikation, ledarskap, motivation, förhandling etc.)

Syftet med denna uppräkning är att visa dels på att kunskaper i projektledning kan användas inom många olika områden men också att en projektledare behöver tillgång till bred kunskap för att effektivt kunna leda projekt.

Vad mitt eget arbete beträffar så arbetar jag främst inom applikationsområde IT-utveckling men jag behöver fortfarande kunskap om övriga applikationsområden som kunden verkar inom för att förstå den affärsnytta som projektet syftar till. Dessutom behöver jag ofta arbeta med andra kulturer, inte minst när utlokaliserade resurser från Indien och andra länder ingår i projektet. Vad generella färdigheter har jag stor nytta av min civilekonomutbildning medan ledaregenskaper är något som jag ständigt försöker utveckla.

Slutligen några andra termer som är bra att känna till:

• Program: Grupp av relaterade projekt som det är fördelaktigt att samordna
• Portfölj (Portfolio): Grupp av inte nödvändigtvis relaterade projekt som samordnas för ett gemensamt strategiskt mål
• Subprojekt: Uppdelning av projekt i mindre hanterbara delar
• Projektkontor (Project Management Office eller PMO): Organisationell enhet som samordnar projektledning

Project Life Cycle

Andra viktiga definitioner i PMBOK är projektlivscykeln (Project Life Cycle) och produktlivscykeln (Product Life Cycle).

Projektlivscykeln definierar de faser som knyter samman projektets början och slut. Olika modeller har olika faser men generellt brukar en fas definiera arbete (vad ska göras), leverabel (vad ska levereras), resurser (vem ska göra och med vad) och kontroll (hur ska fasen godkännas).

Produktlivscykeln däremot definierar de faser som en produkt genomgår på marknaden. En produktlivscykel kan omfatta flera projektlivscykler, t ex i samband med utveckling av en ny produkt eller uppgradering av en befintlig produkt. Den löpande verksamheten är däremot inte ett projekt enligt PMBOK:s definition.

En viktig definition i sammanhanget är intressenter ("stakeholders"). Intressenter omfattar alla individer och organisationer som antingen är engagerade i projektet eller som berörs av det och inkluderar följande:

• Projektledare: Leder projektet
• Projektteam: Utför projektet
• Projektsponsor: Stöder projektet under projektlivscykeln (finansiellt och politiskt)
• Övriga: Anställda, slutkunder, utomstående med inflytande etc.

För projektledaren är det viktigt att identifiera alla intressenter, förstå deras krav och förväntningar samt hantera deras inflytande för att projektet ska bli framgångsrikt. Intressenter kan ha både positivt inflytande (påverkas positivt av projektet) och negativt inflytande (påverkas negativt av projektet) och särskilt det sistnämnda utgör ett hot mot projektet.

Slutligen är det viktigt för projektledaren att förstå det organisationella inflytandet.

• Organisationellt system
• Projektbaserade organisationer: Organisationer som driver projekt (konsultfirmor etc.) eller som styr genom projekt
• Icke projektbaserade organisationer: Organisationer som saknar rutiner och system för att driva projekt
• Organisationskultur: Värderingar, policies, hierarkiska nivåer, arbetsetik etc.
• Organisationsstruktur
• Funktionell: Den funktionelle chefen kontrollerar resurser
• Matris: Projektledaren och den funktionelle chefen delar kontroll över resurser (ju starkare matris, desto mer kontroll för projektledaren)
• Projekt: Projektledaren kontrollerar resurser
• Projektkontor ("Project Management Organization" eller PMO): Projektkontor, om de finns, kan ha allt från en rådgivande funktion till auktoritet över hur projekt ska drivas
• Projektledningssystem: Verktyg, tekniker och metodologier som används för att leda projekt

Vad är då slutsatsen av denna långa uppräkning? Jo, att en projektledare och ett projektteam inte arbetar i ett tomrum utan har en mängd olika inflytanden att beakta. Som konsult i en konsultorganisation, där projekt är en del av vardagen och alla kolleger arbetar för projektets bästa kan det ibland vara svårt att föreställa sig att det faktiskt finns andra prioriteringar att ta hänsyn till.

Något som sällan orsakar problem är mina diskussioner med kundorganisationens funktionella chefer. Som ekonom har jag full förståelse för att t ex ekonomichefen inte vill släppa sina resurser till test under brinnande månadsbokslut. Med bra planering och framförhållning går sådana konflikter att lösa.

Betydligt svårare är det att hantera negativt inflytande. Vad gör man om medarbetare inte är intresserade av att bidra till projektets framgång eller, ännu värre, aktivt motarbetar det? På detta problem finns det inga universallösningar men genom att tidigt identifiera och noggrant analysera alla intressenter kan man lättare och snabbare hantera problemen. I slutändan är det lika mycket en ledarskapsfråga som en projektledningsfråga.

Ett vanligt exempel på negativt inflytande är när man arbetar med konsulter från konkurrerande firmor. Här krockar projektets intresse med firmans intresse och det händer ibland att konkurrerande konsulter håller information inom den egna gruppen eller motarbetar andra konsulters arbete. I sådana fall försöker jag undvika pajkastning och hitta de bästa alternativa vägarna framåt i hopp om att mitt goda exempel ska lysa igenom. Tålamod är då min främste bundsförvant... Tack och lov hör detta till undantagen, oftast så är kolleger professionella, oavsett firmatillhörighet, och jag har både rekommenderat och rekommenderats av "konkurrerande" konsulter.

3. Project Management Processes

PMBOK räknar upp fyra kriterier för att ett projekt ska lyckas:

1. Projektledningsprocesser för att uppnå projektets mål
2. Anpassning av projektledningsplaner till mål
3. Uppfyllande av krav för att möta intressenternas behov och förväntningar
4. Balans mellan de konkurrerande kraven på scope, tid, kostnader, kvalitet, resurser och risk

Projektledningsprocesserna är aggregerade i fem processgrupper och spänner över nio kunskapsområden enligt nedan. PMBOK identifierar totalt fyrtiofyra processer och varje process har en unik uppsättning ingående leverabler att arbeta med och utgående leverabler att ta fram.

Processgrupper (Project Management Processes)

1. Initiering (Initiating): Definiera och auktorisera projektet
2. Planering (Planning): Definiera mål och planera aktiviteter för att uppnå dem
3. Verkställande (Execution): Integrera resurser för att utföra projektplanen
4. Uppföljning och Kontroll (Monitoring and Control): Identifiera avvikelser från planen och vidta åtgärder
5. Avslutning (Closing): Acceptera resultatet och avsluta projektet

Kunskapsområden (Project Management Knowledge Areas)

1. Integrationsstyrning (Project Integration Management): Identifiera, definiera och samordna projektledningsprocesser
2. Scopestyrning (Project Scope Management): Säkerställa att projektet omfattar allt (och endast!) det arbete som krävs för att uppnå projektmålen
3. Tidsstyrning (Project Time Management): Estimera och följ upp aktiviteter så att projektet avslutas i tid
4. Kostnadsstyrning (Project Cost Management): Estimera och följ upp kostnader så att projektet klarar budgeten
5. Kvalitetsstyrning (Project Quality Management): Bestäm och följ upp kvalitetskrav för projektet
6. Personalstyrning (Project Human Resource Management): Organisera och styr projektteam
7. Kommunikationsstyrning (Project Communications Management): Generera, samla in och distribuera projektinformation
8. Riskstyrning (Project Risk Management): Identifiera, analysera och hantera risker (både positiva och negativa)
9. Inköpsstyrning (Project Procurement Management): Anskaffa resurser utanför projektteamet

Orkar du med ett par uppräkningar till? Tabellen nedan sammanfattar relationen mellan processgrupper, kunskapsområden och processer. Observera att processerna anges i den processgrupp där flest aktiviteter äger rum. De flesta processerna återkommer man till under ett projekts gång för referenser och/eller uppdateringar.

Slutligen några av de viktigaste in- och utgående leverablerna:

• Projektförklaring (Project Charter): Auktoriserar formellt projektet
• Scopeförklaring (Project Scope Statement): Anger det arbete som ska utföras och de leverabler som ska tas fram
• Projektledningsplan (Project Management Plan): Anger hur arbetet ska utföras och består av en plan för varje kunskapsområde (kostnadsplan, kvalitetsplan, riskplan etc.)
• Organisationsprocesser (Organization Process Assets): Organisationens historik och erfarenhet av tidigare projekt, används som stöd under projektet och uppdateras efteråt
• Företagets omvärldsfaktorer (Enterprise Environmental Factors): Företagets system och kultur som projektledaren måste ta hänsyn till men också kan föreslå förbättringar av

Det var PMBOK det! Resten av boken går igenom de fyrtiofyra processerna i detalj med specifikationer av tillhörande ingående och utgående variabler. En projektledare ska naturligtvis inte följa alla dessa processer men vara väl förtrogen med dem och anpassa dem till sitt eget projekt. PMBOK är därför bra att referera till under ett projekt.

Men du får ju inte ha med dig PMBOK till certifieringsexamen. Vad behöver du då kunna utantill? Inte så mycket faktiskt. Det finns inga frågor som begär att du ska räkna upp alla processer ur minnet. Däremot måste du förstå syftet med varje processgrupp, varje kunskapsområde och varje process. Du måste utifrån ett i frågan givet scenario förstå vilken del av projektet du befinner dig i och svara därefter. För varje process måste du visualisera aktiviteter och leverabler och ställa dem i relation till din egen verklighet. Du har antagligen inte haft ansvar för alla fyrtiofyra processer men du har åtminstone haft kontakt med dem på ett eller annat sätt. Föreställ dig att du hade haft ansvar och fundera på hur PMBOK:s teorier skulle ha kunnat anpassas till din verklighet. Du kommer då att kunna svara på frågorna genom att tänka logiskt snarare än att hämta fakta ur minnet.

Som jag skrev ovan så utgör PMBOK skelettet i det du behöver veta till certifieringsexamen. Jag tänker därför inte skriva mer om den boken utan övergå till Rita Mulcahy's PMP Exam Prep som verkligen ger dig kött på benen.

Rita Mulcahy's PMP Exam Prep

Mina intryck av the Rita Mulcahy's PMP Exam Prep baserar sig på den sjunde utgåvan.

1. Tricks of the Trade

Tricks of the Trade är Rita Mulcahy's tips på den där lilla extra kunskapen som krävs för att man ska klara certifieringsexamen. Viktigast bland dessa är en lista på 65 "PMIismer"; saker som ofta skiljer PMI:s teorier om projektledning från den verklighet som många projektledare möter. Läs och begrunda varje PMIism och återvänd till listan regelbundet under studierna.

För min del gav följande PMIismer upphov till "aha-upplevelser":

20. Ingen "gold plating": Att lägga till extra funktionalitet är inte förenligt med god projektledningssed. Så mycket för konsultbranschens mantra att överträffa förväntningarna alltså. Å andra sidan är det lätt att förstå om man tänker sig in i kundens situation. När vi byggde hus så blev vi med tiden ganska trötta på entreprenörens "gratis tillägg", såsom en japansk trädgård, när överenskomna leveranser uteblev. Att den japanska trädgården blev ganska ful gjorde förstås inte saken bättre.
36. Ansvar för genomförbarhet: Att projektledaren ansvarar för att genomföra projektet är självklart att men att jag ansvarar för att det är genomförbart också var nytt. Hur ofta har jag inte behövt driva projekt där jag vetat att planen inte varit genomförbar men ändå behövt göra det bästa av situationen? Att kunna säga NEJ är ett tecken på bra integritet men hur lätt är det att göra i praktiken?
47. Projektledaren tar ansvar för personalen: Varför skulle inte projektledaren ta samma ansvar för sina resurser som den funktionelle chefen gör? Kanske har jag bara sett för många dåliga projektledare som fokuserar mer på leverans än på personalen. Det känns tryggt att kunna luta sig mot PMI när jag vill hävda ett projekts mjukare aspekter.
43. Förseningar hanteras genom justeringar av arbete, inte genom mer tid: Jag är van vid att kvalitet är viktigare än tid, kanske för att jag som testledare befinner mig i slutet av projektcykeln och tvingas anpassa mig till tidigare fasers förseningar.
52. Teammöten fokuserar på risk, inte status
Hur många statusmöten har jag inte suttit på där ordet gått runt bordet och de oengagerade deltagarna arbetat samtidigt för att inte förlora tid? PMI har helt rätt i att status kan kommuniceras på annat sätt och att mötena bör fokusera på risker i stället. En status är ju egentligen helt ointressant utom i de fall då den ökar eller minskar en risk och det är bara då som det behövs ett möte för en djup analys.

2. Project Management Framework

Project Management Framework sammanfattar PMBOK:s syn på projektledning. Se till att du kan skilja på följande:

• Projekt är tillfälligt för en unik leverabel, löpande verksamhet är just löpande för standardiserade leverabler
• Projektcykeln består av initiering, planering, verkställande, kontroll och avslut medan produktcykeln typiskt består av införande, mognad och tillbakadragande
• Program är relaterade projekt för effektiv styrning, portfölj är orelaterade projekt för strategiska mål
• Projektledningen är en projektledare med ett team, projektledningskontoret (PMO) är en avdelning som bistår med policies, processtöd och/eller projektledare
• Projektorganisationer styrs av projektledare, funktionella organisationer styrs av funktionella chefer och matrisorganisationer är en kombination av dessa

Ovanstående har du säkert stött på i teorin om du har en akademisk utbildning men har du stött på dem i verkligheten? Visualisera vart och ett av dessa begrepp så att du verkligen förstår dem. I mitt fall kan ett typiskt projekt se ut som följer:

• Projekten handlar vanligtvis om att testa nya system för befintliga produkter
• Jag befinner mig därmed mitt i produktcykeln (med liten risk för förändringar) men i slutet av projektcykeln (med många beroenden från tidigare faser)
• Projektet ingår typiskt i ett större program för att effektivisera en affärsprocess eller uppfylla nya regleringars krav och har därför viss påverkan från andra projekt (t ex delning av testmiljöer, förändring av affärsprocesser etc.)
• Jag behöver balansera kundens projektledningskontor (dokumentmallar, rapporteringsvägar, testverktyg etc.) med mitt eget företags PMO (metodologier, tidredovisning, system för utvärdering etc.)
• Kunden är typiskt en funktionell organisation eller en svag matris där jag måste planera för och äska kundresurser i god tid för att få loss dem från deras ordinarie arbetsuppgifter

Två andra viktiga begrepp som påverkar projektledningen är mål (objectives) och begränsningar (constraints). Projektledaren måste beakta begränsningar i bedömningen av om målen kan nås. Om detta handlar ledningsfilosofin Management by Objectives (MBO). Alla projekt bör avslutas med lärdomar (lessons learnt) om vad som gjordes rätt och vad som gjordes fel.

Allt detta är självklarheter för en erfaren projektledare men det är nyttigt att se allt i ett sammanhang. Hur ofta har du inte känt frustration över oklara mål eller eller osäkerhet över hur en förändring påverkar planen? Detta är inget du kan eliminera men åtminstone mildra genom att alltid ha kvalitet och risker i åtanke samt ta hänsyn till SAMTLIGA begräsningar i förändringsarbetet.

Låt oss anta att den tid jag har till mitt förfogande för att testa minskar (ett alltför vanligt scenario). Det är lätt att peka på att risken ökar och kvaliteten minskar i och med att defekter upptäcks senare eller kanske inte alls. Detta leder naturligt till minskad kundtillfredsställelse då systemet inte uppfyller de krav som ställts. Resurser kan bli ett stort problem om dedikerade testare inte har möjlighet att planera om sina kalendrar. I värsta fall måste scopet ändras, d v s delar av funktionaliteten lyftas ut och tillfälliga "workarounds" tas in i stället. I slutändan blir detta en kostnadsfråga där kostnaden mot att få in funktionaliteten snabbt måste vägas mot kostnaden för att klara sig utan den under en övergångsperiod. (Noteras kan i sammanhanget att övertidsarbete enligt PMI är en absolut sista utväg för att hantera begräsningar, en riktlinje som många projekt bryter mot.)

3. Project Management Processes

Kapitel tre inleds med det kanske bästa hjälpmedlet i Rita Mulcahy's bok: Rita's Process Chart. Detta är en översikt som sammanfattar hela projektledningsprocessen och någonting som du måste memorera till certifieringsexamen. Ett bra tips för att memorera detta är Rita's process game där du klipper ut och arrangerar alla processer efter processområde och (endast för planering) i rätt ordning.

Av både copyrightskäl och respekt för författarens arbete vill jag inte återge översikten i dess helhet utan bara min egen sammanfattning. Jag har nämnt processerna vid nyckelord och grupperat dem efter hur jag anser att de logiskt hör ihop (t ex kultur och processer i samma grupp) och rekommenderar att du gör detsamma.

Förstår du varför t ex aktiviteter kommer före nätverksdiagram? Oroa dig inte, du kommer i senare kapitel förstå varför och därmed kunna svara på frågor genom logik snarare än memorering. Nu några ord om de olika processgrupperna.

Initiering

Initiering har tre övergripande syften (Rita's gruppering):

• Projektledare: Projektledaren är med från början, får sin auktoritet definierad och deltar i initieringen
• Planering: Många planeringsaktiviteter påbörjas redan under initieringen för att sedan utvecklas och formaliseras i planer under planeringen
• Business case: Projektledaren inte bara vet varför projektet initieras utan avgör också om det är genomförbart givet begränsningarna

Det här kan skilja sig från många projektledares vardag, inklusive min. Testledare kommer ju tyvärr ofta in senare i projektet, trots att såväl testmetodik som projektledningsmetodik rekommenderar annat.

På sistone har jag föresatt mig att förstå projektets syfte och beakta det i andra beslut. Som exempel kan nämnas ett projekt där förseningar i testerna av ett lagersystem ledde till att tidplanen inte höll. Var det skäl nog att avsluta projektet? Nej, ett av syftena med det nya lagersystemet var att klara julruschen men det gamla systemet hade visat sig klara andra ruscher oväntat bra. Tid var därmed inte längre en lika kritisk begränsning och det gick att skjuta på införandet av systemet till efter jul.

Planering

Planering har fyra övergripande syften (min egen gruppering):

• Planer: Påbörja planer för styrning av alla kunskapsområden (scope, tid, kostnader, kvalitet, personal, kommunikation, risk och inköp)
• WBS: Bryt ned scope till styrbara delar (Work Breakdown Structure eller WBS) och använd detta för att detaljplanera vad som görs av vem och när
• Iterering: Identifiera och analysera risker och GÅ SEDAN TILLBAKA och planera om de delar som påverkas av riskerna
• Godkännande: Avsluta alla planer, inhämta godkännande och håll ett kickoff-möte med alla intressenter för att säkerställa att de är införstådda med planerna

Att göra övergripande planer och bryta ned i mindre delar är naturligt för mig som konsult i allmänhet och som testledare i synnerhet. I testplanen tittar jag övergripande på det system och de processer som ska testas och därefter bryter jag ned kraven i testbara delar.

Iterering är tyvärr något som ofta hoppas över då projektramarna redan är beslutade på högre nivå. Jag är därför van vid att göra det bästa av situationen och minimera de risker som finns givet begränsningarna. Det är ett flexibelt och uppskattat arbetssätt men INTE enligt PMI:s normer.

Godkännande är lättare att förhålla sig till. Kanske är detta ovanligt i amerikansk företagskultur men i Sverige är det naturligt att i demokratisk anda engagera alla intressenter.

Verkställande

Verkställande har fyra övergripande syften (min egen gruppering):

• Plan: Följ plan och ta fram leverabler (planen ska vara så bra att det "bara" är att följa den)
• Proaktivitet: Förutse och motverka problem i stället för att reagera på dem (t ex genom kvalitets- och riskstyrning)
• Resurser: Se till att personal och resurser finns och är förberedda när de behövs (men slösa inte tid på att detaljstyra)
• Kommunikation: Samla in relevant information och kommunicera till berörda på lämpligt sätt

Även detta är naturliga arbetsuppgifter för mig. Testschemat behöver ofta ändras beroende på om en funktion kan testas eller ett fel rättats men själva testaktiviteterna förblir normalt oförändrade. Proaktivitet ligger i testledarens natur. Även om jag inte kan påverka vissa saker, t ex problem med testmiljön, så kan jag åtminstone ha beredskapsplaner för det.

Vad resurser beträffar så behöver jag, som så många andra, lära mig att inte detaljstyra. Har man en gång själv suttit som testare så är det svårt att hålla sig borta från "markarbetet". Att förstå systemet man testar kommer alltid att vara viktigt. Sedan gäller det att inte gå över gränsen mellan mentor och "dadda" utan att lita på sina testare.

Kommunikation slutligen är ett svårt område. Standardrapporter från testverktyg i all ära men det gäller att anpassa informationen till mottagarna och hitta balansen mellan för lite information (som ingen har nytta av) och för mycket information (som ingen orkar läsa). Ofta ändras ju också mottagarnas behov under projektet. Jag löser det genom att fråga både före och efter vilken information som efterfrågas.

Uppföljning och Kontroll

Uppföljning och Kontroll har fyra övergripande syften (min egen gruppering):

• Utfall mot plan: Mät utfall, jämför med plan och agera på eventuella varianser
• Förändringskontroll: Föreslå förändringar, utvärdera dem med integrerad förändringskontroll och fatta beslut
• Uppföljning: Följ upp planer, processer, kvalitet och risker och gör förändringar vid behov
• Kommunikation: Inhämta information från intressenter (både formellt godkännande och informell tillfredsställelse) och kommunicera utfall

Observera några viktiga skillnader mellan Verkställande och Uppföljning och Kontroll:

• Verkställande följer upp avvikelser från plan i teammedlemmarnas resultat, Uppföljning och Kontroll följer upp avvikelser i projektets resultat
• Verkställande föreslår och implementerar förändringar, Uppföljning och Kontroll föreslår och godkänner/avslår förändringar
• Verkställande säkrar kvalitet i arbetet, Uppföljning och Kontroll utvärderar och förbättrar kvaliteten
• Verkställande fokuserar på projektteamets kommunikation, Uppföljning och Kontroll fokuserar på kommunikation med övriga intressenter

Uppföljning och Kontroll är ett område som många får fel på och vid första anblicken kan det verka svårt. Jag tror dock att det mer är en fråga om perspektiv. Självklart följer projektledare upp det som kan följas upp, man måste bara intala sig att certifieringsexamen frågar om uppföljning i en "perfekt" värld där uppföljningen kan vara så mycket noggrannare.

Som testledare utövar i alla fall jag mycket uppföljning, om än i mindre skala. Genomförda testfall jämförs med planerade, förändringsbehov identifieras och kommuniceras (även om jag inte deltar i själva förändringsbeslutet) och testplanen uppdateras löpande för att hantera nya förutsättningar.

Vad kommunikationen beträffar så håller jag såväl formella "go/no go-möten" där beslut fattas om systemet uppfyller kraven som arbetar nära de slutliga användarna och kan fånga upp deras känsla och förtroende för det nya systemet.

Avslutning

Avslutning slutligen har två övergripande syften (min egen gruppering):

• Formellt avslut: Slutrapport, godkännande av leverabler, reglering av kontrakt etc.
• Överlämning: Överlämning av leverabler, arkivering av dokument

Det här är ett lätt område även om du inte deltagit i det. Själv är jag mest inblandad i de informella delarna, såsom överlämning av processbeskrivningar och systemmanualer. De formella delarna är dock desamma också i andra sammanhang, t ex det som sker när en anlitad hantverkare är klar (eller det som borde ske om du har dåliga erfarenheter...)

Alla dessa processgrupper kommer att belysas ytterligare genom de olika kunskapsområdena i kommande kapitel.

Slutligen några ord om de långa listorna av ingående och utgående variabler i PMBOK. Försök inte memorera dem utan följ Rita's råd och utgå från processen i stället. Om du vet syftet med en process så kan du också föreställa dig vad du behöver för att kunna utföra en process och vad du har när du är klar med processen.

4. Integration Management

Integrationsstyrning eller Integration Management handlar om att samordna alla kunskapsområden (scope, tid, kostnader, kvalitet, personal, kommunikation, risk och inköp) och omfattar följande processer:

• Initiering: Ta fram projektförklaring (project charter)
• Planering: Ta fram projektledningsplan (project management plan)
• Verkställande: Styr projektarbetet
• Uppföljning och Kontroll: Följ upp och kontrollera projektarbetet samt utför integrerad förändringskontroll
• Avslutning: Avsluta projektet

Initiering: Ta fram projektförklaring (project charter)

Projektförklaringen ligger till grund för projektet och projektplanerna och har följande egenskaper:

• Ger projektet erkännande och projektledaren auktoritet att spendera resurser
• Identifierar mål och övergripande krav (detaljeras i plan)
• Identifierar begränsningar och övergripande risker (detaljeras i plan)
• Identifierar antaganden (används för att detaljera krav, scope och risker)
• Kopplar projektet till företagets strategi

Se projektförklaringen som ett uttryck för kundens (projektsponsorns) vilja och ett startskott för projektledarens (ditt) arbete. Den kan visserligen skrivas av projektledaren men måste godkännas av projektsponsorn. Som projektledare måste du förstå varför kunden valt projektet (dess business case) och vilka förutsättningar projektet har. Projektförklaringen kan föregås av en arbetsbeskrivning (Statement of Work eller SOW) där kunden eller sponsorn redogör för sina behov.

Mål och krav känner säkert de flesta projektledare till när projektet börjar men begränsningar och antaganden? Kom ihåg att det är ditt ansvar att bedöma om projektet kan uppnå målet och du måste då veta vilka faktorer som begränsar dina handlingsalternativ och bedöma hur rimliga antagandena är. Till din hjälp så här i början har du de tidigare nämnda ingående leverablerna organisationsprocesser (organizational process assets) och omvärldsfaktorer (enterprise environmental factors). Uppfinn inte hjulet på nytt utan ta till vara existerande processer, historia, system och kultur. Även om de inte alltid är bra på dina projekt så kom ihåg att PMI förutsätter en perfekt värld.

Hur många gånger har du sett en projektförklaring? Det troliga är att projektet initierats helt internt och att projektförklaringen står att finna i kundens inbjudan till offerter och jag har tyvärr aldrig varit med i det offertarbete som ligger till grund för mitt projekt. I andra fall kan det vara så att projektet initieras som en del av ett större och bara har föregåtts av diskussioner och möten som inte protokollförts. Icke desto mindre är det en lärdom jag tar med mig från detta kapitel att gräva fram de "initieringsdokument" som finns och utnyttja kunskapen i dem min planering. Jag har varit på oklart definierade projekt där jag fått arbeta enligt devisen "skriv planen först och planera sedan när du vet mer." Hur lätt det blir att verkligen hitta dessa "initieringsdokument" är dock en annan fråga...

Ytterligare en viktig sak i sammanhanget är de metoder för projektval som finns:

Till de ekonomiska modellerna hör nuvärdesberäkning eller Net Present Value (summan i kr av framtida intäkter minus kostnader med hänsyn till inflation), internavkastning eller Internal Rate of Return (den "ränta" i procent man tjänar på projektinvesteringen), återbetalningstid eller Payback Period (tiden innan investering tjänats igen) och kostnads- och intäktsanalys eller Cost Benefit Analysis (kvoten mellan intäkter och kostnader. Man behöver normalt inte använda dessa begrepp i beräkningar utan bara känna till att de kan ligga till grund för val av projekt.

Andra begrepp att känna till är ekonomiskt värde eller Economic Value Added (intäkter minus kostnader), alternativkostnad eller Opportunity Cost (nuvärdet av bortvalda alternativ), oundvikliga utgifter eller Sunk Costs (redan spenderade pengar) samt arbetande kapital eller Working Capital (monetära tillgångar minus skulder). Slutligen bör du kunna skilja på rak avskrivning eller Straight Line Depreciation (lika mycket värdeminskning varje år) och accelererad avskrivning eller Accelerated Depreciation (ökande värdeminskning varje år). Om du inte har stött på dessa begrepp tidigare så gå igenom Rita's exempel för att förstå dem.

Planering: Ta fram projektledningsplan (Project Management Plan)

Projektledningsplanen bygger på projektförklaringen och integrerar alla processer, planer och baselines.

• Projektledningsprocesser (vilka av PMBOK:s 44 processer som ska användas och hur)
• Planer för kunskapsområden (scope, schema, kostnader, kvalitet, personal, kommunikation, risk och inköp)
• Planer för styrning av krav, förändringar, konfigureringar och processförbättringarar
• Baselines för scope, schema och kostnader

Se planerna som något projektledaren kan referera till under projektets gång och baselines som något att mäta projektets framgång mot. För varje plan ska du fråga dig hur du ska definiera, planera, styra och kontrollera projektet. Under planeringen uppdateras planerna i en iterativ process och den slutliga planen ska vara accepterad, godkänd, realistisk och formell. Till planen hör också projektdokument som intresseregister, kravdokumentation, aktivitetslista, kvalitetsmetrics, riskregister, problemlogg, förändringslogg och mycket annat.

Testplaner är något som jag är van vid att skriva och referera till under projektets gång. Testmetodologierna är fulla av standarder för testplaner, testansatser, testvillkor, testscheman o s v för att styra och kontrollera testarbetet. Ett problem är dock att få andra intressenter att engagera sig i planen. Projektledaren noterar milstolparna och testresurserna uppdaterar sina kalendrar men någon återkoppling av testplanen i sin helhet får jag sällan. (Jag minns en kollega som hävdade att han brukade limma ihop sina planer för att se om någon skulle reagera, vilket någon aldrig gjorde, men så långt vill jag inte gå.) Här kan jag kanske fundera på alternativa presentationssätt, såsom lättlästa "populärversioner" av testplanen till seniora medarbetare och engagerande planeringsaktiviteter med juniora medarbetare.

Verkställande: Styr projektarbetet

Projektarbete ur projektledarens perspektiv innebär att hålla ihop alla aktiviteter. Som ovan nämnt handlar det om att följa projektledningsplanen, hjälpa projektteamet att utföra arbete och ta fram leverabler samt hålla intressenter informerade och engagerade. Det räcker dock inte med denna helhetssyn utan det är också viktigt att följa varje individuell plan och beakta hur händelser i ett område påverkar andra områden. Om t ex en ny risk identifieras så måste dess påverkan på VARJE annat kunskapsområde utvärderas.

Här är ännu en bra lärdom jag kan ta med mig i mitt arbete som testledare. Att hålla ihop testarbetet och agera "curlingförälder" åt mina testare är en intensiv och stimulerande roll. Däremot kan jag bli bättre på att presentera resultat i ett helhetsperspektiv. Om vi t ex får en försening i schemat kan jag strukturera följderna i termer av scope (vad händer om en funktion inte är klar vid driftsättning?), kostnad (blir det några merkostnader för att testa ikapp förseningen?), kvalitet (hur effektiva blir testerna om de måste komprimeras?), personal (finns det testare tillgängliga?), kommunikation (vilken kommunikation behövs till slutanvändarna?), risk (vilka fel kan förbli oupptäckta?) och inköp (är investeringar i testmiljö eller driftsavtal ett alternativ?). På så vis kan mottagarna av informationen lättare relatera den till sina egna ansvarsområden. Även om du inte arbetar inom alla kunskapsområden kan du fortfarande tänka i termer av integration.

Uppföljning och Kontroll: Följ upp och kontrollera projektarbetet samt utför integrerad förändringskontroll

Uppföljning och Kontroll av projektarbetet handlar om att säkerställa att projektarbetet följer plan. Alla avvikelser från plan måste åtgärdas och alla åtgärder som påverkar plan måste hanteras genom integrerad förändringskontroll. Tabellen nedan sammanfattar detta:

Följande kanske skiljer PMI:s integrerade förändringskontroll mot många projektledares verklighet och kan vara bra att ha i minnet:

• Förändringar ska förebyggas genom proaktivt arbete (ett perfekt planerat projekt ska inte behöva förändras)
• Förändringar ska bedömas utifrån om de är förmånliga för det aktuella projektet (annars ska de avslås eller flyttas till ett annat projekt)
• Förändringar ska kommuniceras till alla intressenter som påverkas

Förändringskontroll är en viktig del i testarbetet. Det är trots allt testarna som ska testa och verifera alla förändringar. Mitt arbete blir därför lättare ju mer helhetssyn jag har på förändringsarbetet.

Ett exempel på detta är när vi identifierade en förändring i de tredjepartsmeddelanden ett nytt system skulle hantera. Systemet var bara anpassat för det gamla meddelandeformatet. Vi kunde visserligen inte förebygga förändringen då den kom från tredje part men vi kunde åtminstone förebygga problem genom att tidigt kontrollera förändringen. I sammanhanget upptäckte vi också att andra avdelningar skulle påverkas och det komplicerade saken. Hörde de förändringarna till vårt projekt? Krasst sett så skulle inte "vår" avdelning tjäna på en förändring för de andra avdelningarna. Vi anpassade ändå förändringen efter de andra avdelningarnas behov då det var enklare än att starta ett helt nytt projekt men helt rätt enligt PMI var det väl inte. Däremot var vi noga med att dokumentera och kommunicera det hela till alla berörda.

Avslutning: Avsluta projektet

Avslutning handlar helt enkelt om att få formell acceptans och överlämna alla leverabler. Integreringen ligger i att alla kunskapsområden avslutas ordentligt. Inköpsavtal ska regleras, personal ska få sin utvärdering, projektdokument ska arkiveras o s v. Avslutning görs oavsett om projektet fullföljts eller avslutats i förtid.

Precis som fallet är med iterering så är detta område som inte alla projektledare har praktisk erfarenhet av. Trots det finns också här bra lärdomar. Jag har till exempel inte tänkt på att utvärdera mina "inlånade" testare från kundens personal eftersom jag inte haft något formellt chefskap över dem. Ändå är jag säker på att både de och deras chefer hade uppskattat det. Låt de nio kunskapsområdena genomsyra allt ditt projektledningstänkande, både på certifieringsexamen och i ditt dagliga arbete!

5. Scope Management

Scopestyrning eller Scope Management handlar om att definiera vad som ska göras och kontrolllera att det (och ingenting annat) görs. Det är därför viktigt att krav från alla intressenter samlas in, att både scope och eventuella förändringar formellt godkänns samt att inget extra (gold plating) levereras. Skilj på produktscope (vad ska levereras) och projektscope (hur ska det levereras). Hur scope ska definieras och kontrolleras beskrivs i en scopestyrningsplan (Scope Management Plan).

• Initiering: -
• Planering: Samla in krav, definiera scope och skapa WBS
• Verkställande: -
• Uppföljning och Kontroll: Verifiera och kontrollera scope
• Avslutning: -

Samla in krav

Syftet med kravinsamlingen är att utifrån projektets övergripande krav (från initieringsfasen) specificera ALLA krav på produkt OCH projekt från ALLA intressenter samt ALLA antaganden som ligger bakom. Du kan inte förutsätta att projektsponsorn har denna detaljkunskap utan måste själv samla in den från intressenterna. Exempel på insamlingsmetoder är historiska data, intervjuer, delfiteknik (granskning av experter som förblir anonyma för varandra), mindmaps, protoyper etc. Än svårare är det att balansera och prioritera motstridiga krav. Rita rekommenderar nedanstående prioritetsordning. Glöm inte att du som projektledare både kan och ska säga nej till krav som inte är i projektets intresse.

1. Business case
2. Projektförklaring
3. Projektscopeförklaring
4. Projektbegränsningar

Två viktiga leverabler från kravinsamlingen är kravstyrningsplanen (Requirements Management Plan) och spårbarhetsmatrisen (Requirements Traceability Matrix). Kravstyrningsplanen specificerar hur krav ska identifieras, analyseras och kontrolleras. Spårbarhetsmatrisen länkar kraven till projektmålen genom att dokumentera källa, ägare och status för alla krav. Observera att denna definition kan skilja sig från andra definitioner. Inom test innebär spårbarhet att krav länkas till testfall och testresultat medan spårbarhet i testverktyget HP Quality Center innebär att krav som kan påverka varandra kopplas samman.

Som testledare är det viktigt att jag är med redan i kravinsamlingen, inte bara för att förstå vilka krav som behöver testas utan också vad som krävs för att de ska accepteras. Jag kan då också bedöma i vilken mån ett krav är testbart och därmed bidra till projektets vara eller inte vara. Krav som att ett nytt system ska vara "förstklassigt" eller "i framkant" (jo, jag har sett sådana krav) kan ju aldrig testas och därmed kan man aldrig avgöra om projektet blir framgångsrikt eller inte.

Definiera scope

Syftet med att definiera scope är att specificera vad som ska göras och inte göras i termer av produktscope, projektscope, leverabler, avgränsningar, acceptanskriterier, begränsningar och antaganden. Allt detta sammanfattas i en projektscopeförklaring (Project Scope Statement).

Det händer tyvärr att projekt får ett löst definierat scope. Det är en sak att iterera fram ett scope under planeringen, en helt annan att göra det under verkställandet. Min lärdom är att se till att mitt eget område har ett tydligt och godkänt scope för att slippa onödigt arbete och omarbeten.

Skapa WBS

WBS står för Work Breakdown Structure, en hierarkisk nedbrytning av projektet i hanterbara delar. En sådan nedbrytning bör göras enligt följande:

De minsta beståndsdelarna i ett WBS kallas arbetspaket (work packages). De kan eventuellt grupperas i kontrollkonton (control accounts) för att styra kostnaderna. Varje arbetspaket beskrivs i detalj i ett WBS-register (WBS dictionary) och där även de schemaaktiviteter (schedule activities) som krävs för att ta fram leverablerna beskrivs. WBS, WBS-lexikon och projektscopeförklaring utgör tillsammans projektets scopebaseline, den referensram projektledaren använder för att avgöra om projektet är inom scope.

För ett utvecklingsprojekt utgörs första nivån på ett WBS normalt av den använda projektmetodens faser, t ex Analys, Design, Utveckling, Test och Driftsättning. "Mitt" testprojekt bryts sedan ned i de aktuella testfaserna, t ex Integrationstest, Systemtest, Prestandatest och Acceptanstest. Ytterligare nedbrytningar av WBS är ovanliga, även om varje arbetspaket behöver brytas ned i ytterligare schemaaktiviteter, såsom testplanering, testanalys, testdesign och testexekvering. Observera att ett WBS alltså inte har någon koppling till projektets beslutshierarkier eller tidplan. Ett arbetspaket som Acceptanstest omfattar både testledare och testare och sträcker sig från planering till avslutning.

Verifiera och kontrollera scope

Verifiera scope handlar INTE om att säkra att du planerat rätt scope (detta gör du genom att få din projektscopeförklaring godkänd). Det handlar heller INTE om att få ett slutligt godkännande av projektet (detta får du i avslutningsfasen). I stället handlar det om att som en del av uppföljningen och kontrollen löpande under projektets gång möta kunden och/eller projektsponsorn och få acceptans på leverabler. Inför varje sådant möte behöver du följande:

• Färdigställda och kvalitetskontrollerade leverabler att acceptera
• Scopebaseline (WBS, WBS-lexikon och projektscopeförklaring) att jämföra leverablerna mot
• Eventuella korrektiva eller preventiva åtgärder utförda
• Kravdokumentation och spårbarhetsmatris att referera till
• Integrerad förändringskontroll för att hantera eventuella förändringsönskemål

Hur skiljer sig då Verifiera scope från Kontrollera scope? Jo, helt enkelt genom att du som projektledare först måste kontrollera scope innan du sätter dig med kund och sponsor för att verifiera scope.

Att verifiera och kontrollera scope låter lätt på papperet men kan ha sina utmaningar i verkligheten. Jag har varit på projekt där scope har godkänts, kontrollerats och verifierats men där externa händelser (såsom organisationsförändringar hos både kund och program) ständigt ändrat mitt projekts scope. Om jag hade varit en projektledare anställd hos kunden hade jag kunnat avsluta projektet och starta ett nytt (när kunden är redo för ett nytt scope) men hur lätt är det när jag bara är anlitad av kunden? Nu blev jag kvar i någon sorts stödfunktion i väntan på nytt scope, visserligen med både kundens och min egen arbetsgivares samtycke, men ändå. Till slut kom projektet igång igen, i stort sett enligt min ursprungligen definierade scope. Med facit i hand skulle jag ha argumenterat bättre för min egen projektscopeförklaring men då hade jag kanske inte kunnat stanna längre än planeringsfasen. Lärdomen är att bra scopestyrning kräver stark integritet och tro på den egna förmågan.

6. Time Management

Tidsstyrning eller Time Management handlar om att planera för hur och av vem en schemastyrningsplan (Schedule Management Plan) ska tas fram och hur den sedan ska kontrolleras.

• Initiering: -
• Planering: Definiera och sekvensera aktiviteter, estimera resurser och varaktighet, ta fram schema
• Verkställande: -
• Uppföljning och Kontroll: Kontrollera schema
• Avslutning: -

Definiera och sekvensera aktiviteter

Aktiviteter är det arbete som krävs för att producera arbetspaketen från WBS. Aktiviteterna måste vara så detaljerade att du kan estimera, schemalägga och följa upp dem. Resultatet av processen definiera aktiviteter är en aktivitetslista med aktivitetsattribut samt milstenar (viktiga händelser i schemat, t ex deadlines).

Nästa process är att sekvensera aktiviteterna. Resultatet är ett nätverksdiagram som visar i vilken ordning aktiviteterna måste utföras. En vanlig metod för att rita nätverksdiagram är att använda boxar för aktiviter och pilar för beroenden (Precedence Diagramming Method eller Activity-on-Node). Det finns fyra typer av relationer och tre typer av beroenden att känna till:

Två andra viktiga begrepp i sammanhanget är "leads" (antal dagar före det att en aktivitet slutar som nästa kan börja) och "lags" (antal dagar efter det att en aktivitet slutar som nästa kan börja.

Ta följande konkreta exempel: Testdesign och testexekvering har en FS-relation och ett obligatoriskt beroende. Testdesign har dessutom en lag på ytterligare en vecka för granskning och godkännande. Detta innebär att testexekvering kan börja först en vecka efter det att testdesign slutat och det går inte att utföra aktiviterna parallellt.

Nätverksdiagram har många användningsområden. De ger en översiktsbild som stödjer såväl planering av aktiviteter som uppföljning av dem. De kan också identifiera nya risker, t ex om många aktiviteter är beroende av en aktivitet som bara en person kan utföra. I min egen vardag är de också värdefulla för att illustrera arbetsflöden så att varje testare vet hur de egna testerna relaterar till andras tester. På så vis vet de vem de ska fråga om t ex en ingående testorder inte fungerar som förväntat eller vem de ska informera när en behandlad testorder ska verifieras.

Estimera resurser och varaktighet

När du vet vilka aktiviteter du har och i vilken ordning de kommer är det dags att estimera dem. Estimering omfattar såväl vad som behövs för aktiviteten som hur lång tid den tar. Estimering görs lämpligen av den som ska utföra aktiviteten medan det är ditt ansvar att de har tillräckligt med information. Så kallad "padding", att lägga till extra tid för att kompensera för bristande information, är inte förenligt med god projektledningssed. Kom också ihåg att även om din chef sätter en deadline så är det fortfarande du som ansvarar för att projektet är genomförbart på den tiden.

Det finns olika typer av estimering som du behöver kunna till certifieringsexamen:

• Enpunktsestimering (one-point): Ett estimat per aktivitet
• Analog estimering (top-down): Totalt estimat för projektet (t ex baserat på tidigare erfarenhet) som sedan bryts ned
• Parametrisk estimering: Estimat baserat på variabler (t ex antal testfall)
• Regressionsanalys: Historiskt samband mellan två variabler används för att skapa matematisk formel
• Inlärningskurva: Ju fler gånger något görs, desto kortare tid tar varje gång
• Tumregler (heuristics): Antagna samband, t ex test tar lika mycket tid som design
• Trepunktsestimering (three-point): Kallas även Program Evaluation and Review Technique (PERT) och baseras på pessimistiska (P), mest sannolika (M) och optimistiska (O) estimeringar enligt följande formler (måste memoreras):
• Förväntat värde: (P+4M+O)/6
• Standardavvikelse: (P-O)/6
• Varians: Standardavvikelsen upphöjt till 2
• Range: Förväntat värde +/- Standardavvikelse

Observera att formlerna ovan gäller för enskilda aktiviteter. För hela projekt måste du summera samtliga aktiviteters varianser och ta kvadratroten ur denna summa för att få projektets standardavvikelse. Till certifieringsexamen behöver du dock inte utföra avancerade beräkningar och behöver således inte miniräknare.

Estimeringen avslutas med en reservanalys. Reserver används för att hantera återstående risker (alltså inte för att hantera dåliga estimat) och kan vara av två slag (se vidare Risk Management):

• Beredskap (contingency): Reserver för risker som återstår efter planeringen av riskrespons
• Styrning (management): Reserver för oförutsedda risker

Estimering på lägre nivåer är inget ovanligt för en konsult men på högre nivåer används normalt avancerade verktyg. Lyckligtvis är formlerna ganska enkla att memorera. Ta följande konkreta exempel:

Ta fram schema

Ta fram ett schema innebär att du sammanställer tid och aktiviteter i en initial kalender. Det innebär att du måste ta hänsyn till resursers tillgänglighet och skilja på arbetsdagar och lediga dagar. Du fortsätter sedan med att analysera schemat med följande metoder:

• Kritisk väg (critical path): Identifiera den "längsta vägen" genom ditt aktivitetsdiagram och hur lång tid den tar (och därmed den kortaste tid projektet tar)
• Schemakomprimering (schedule compression): Omläggning av schemat för att komma ikapp plan
• Snabbspår (fast tracking): Utföra aktiviteter som tidigare var planerade i serie parallellt
• Krasch (crashing): Se över andra begränsningar, t ex ta in extra resurser (kostnad) för att utföra aktiviteter snabbare (tid)
• Scenarioanalys (what-if): Analysera resultat om förutsättningar ändras, t ex genom Monte Carlo-analys (datorsimulering)
• Resursutjämning (resource leveling): Utjämna resursbehov över tiden för att minska riskerna (även om tiden därmed ökar)
• Kritisk kedja (critical chain): Beräkna den kritiska kedjan genom att schemalägga aktiviteter så sent som möjligt, lägga till resursberoenden och lägga in buffertar vid kritiska milstolpar

Kritisk väg är viktig att känna till eftersom förseningar i aktiviteter längs den kritiska vägen försenar hela projektet. Det är också viktigt att känna till vägar som i tid är nära den kritiska vägen (near-critical path) eftersom förseningar kan göra så att dessa vägar blir kritiska. Ett viktigt begrepp i detta sammanhang är float (slack).

• Total float (slack): Den tid som en aktivitet kan försenas utan att slutdatumet för projektet försenas
• Fri float (slack): Den tid som en aktivitet kan försenas utan att startdatumet för nästa aktivitet försenas
• Projekt-float (slack): Den tid som ett projekt kan försenas utan att det utlovade slutdatumet försenas

Aktiviteter längs den kritiska vägen har alltid noll i float eftersom förseningar har en direkt påverkna på projektet. Aktiviteter som å andra sidan har float kan utnyttjas för att t ex resursutjämning. Float kan beräknas på två sätt:

• Senaste start (late start) - Tidigaste start (early start)
• Senaste slut (late finish) - Tidigaste slut (early finish)

En aktivitet som tidigast kan börja dag 0 och senast dag 3 har alltså en float på 3 (d v s starten kan skjutas upp i upp till 3 dagar). Om aktiviteten hade legat på den kritiska vägen hade den behövt börja senast dag 0 och alltså haft en float på 0. Rita har flera övningar där du får rita nätverksdiagram och beräkna float.

Kritisk kedja skiljer sig från kritisk väg genom att större hänsyn tas till kritiska resurser. Om resurser hade varit obegränsade hade resultatet varit detsamma som kritisk väg. Till certifieringsexamen behöver du dock inte känna till detaljerna i denna metod.

Observera att övertid inte är förenligt med god projektredovisningstid och bara ska användas som sista utväg. (Hur vanligt är det i din erfarenhet?)

Resultatet av denna process är ett projektschema (project schedule) samt en schemabaseline (schedule baseline) att mäta projektet mot. Tabellen nedan anger olika former av projektscheman och deras tillämpningsområden:

Begreppet kritisk väg ser elegant ut i teorin men jag måste medge att jag inte sett det i praktiken. Visst finns det olika "vägar" i projekten men det vanliga är ändå en "huvudväg" där aktiviteterna måste gå i en viss ordning med flera "sidovägar" som inte påverkar huvudvägen. Förseningar är normalt av den arten att så gott som samtliga aktiviteter stoppas (t ex att testmiljön ligger nere). Ett annat problem med just test är svårigheten i att estimera i detalj. Man kan uppskatta totala testtider för olika faser och funktioner men när man kommer ned på testfallsnivå så är testtiden helt beroende av hur testet går.

Jag är heller inte säker på att de olika formerna av projektscheman är tillämpliga i mitt arbete. Jag har nog inte träffat någon ledare som skulle nöja sig med att bara se milstolparna, de vill kunna följa hur det går också. Möjligen kan jag använda nätverksdiagram mer när jag kommunicerar med mitt team, inte bara för att visa hur testerna ska genomföras utan också för att visa hur det går.

Kontrollera schema

Att kontrollera schemat innebär att projektledaren mäter utfall mot schemabaseline och vidtar korrektiva och preventiva åtgärder för att hålla schemat. Projektledaren måste också agera proaktivt genom att identifiera och påverka källor till förändring samt omestimera projektet för att säkerställa att antagandena från planeringen fortfarande är korrekta. Kom ihåg att projektledaren är ansvarig för att schemat hålls och om projektet inte kan avslutas i tid kan det vara bättre att avsluta det i tid än att fortsätta slösa med resurser.

Det här är en kort beskriven process men den innehåller många bra tips.

• Mät utfall mot schemabaseline: De flesta testverktyg har standardrapporter som jämför planerade testfall med utförda testfall
• Korrektiva åtgärder: Genom att via nätverksdiagram förstå hur testfall hänger ihop kan jag lätt ändra testschemat vid behov
• Preventiva åtgärder: Genom att komma in tidigt i projektcykeln kan jag hjälpa till att kvalitetssäkra ingående testleverabler (krav etc.) samt ställa krav på testmiljön
• Påverka källor till förändring: Genom att tidigt engagera slutanvändarna kan jag hjälpa till att identifiera felaktiga eller saknade krav i stället för att upptäcka dem först i test
• Omestimera projektet: Vid varje schemaändring omvärderar jag mina tidigare antaganden om hur lång tid testfall tar men bör göra det också när testerna går enligt plan

7. Cost Management

Kostnadsstyrning eller Cost Management handlar om att planera för hur kostnader ska planeras och kontrolleras. Planen sammanställs i en kostnadsstyrningsplan (Cost Management Plan). Några viktiga begrepp i sammanhanget är livscykelkostnad eller Life Cycle Costing (kostnad för produktens livscykel, inte bara projektet), värdeanalys eller Value Analysis (hitta lägsta möjliga kostnad) samt kostnadsrisk eller Cost Risk (kostrelaterade risker, t ex vem som bär risken för en kostnad).

• Initiering: -
• Planering: Estimera kostnader och fastställa budget
• Verkställande: -
• Uppföljning och Kontroll: Kontrollera kostnader
• Avslutning: -

Estimera kostnader

Estimering av kostnader kan göras med samma metoder som estimering av tid (enpunkts, analog, parametrisk och trepunkts). Estimering kan också göras bottom-up, d v s för enskilda aktiviteter eller arbetspaket som sedan summeras på kontrollkontonivå och projektnivå. När du estimerar behöver du ta hänsyn till rörliga (ökar med produktion), fasta (oberoende av produktion), direkta (relaterade till ditt projekt) och indirekta (relaterade till flera projekt) kostnader. Vidare behöver du titta på baselines, scheman, personalplaner, riskregister, historiska data och företagets omvärldsfaktorer.

Estimeringar har tre grader av noggrannhet:

• Grovt estimat eller Rough Order of Magnitude (ROM) Estimate: Görs under projektinitiering, normalt +/-50 %
• Budgetestimat: Görs under projektplanering, normalt -10 % till + 25%
• Definitivt estimat: Görs i takt med att projektet fortlöper, normalt +/-10 %

Estimering av kostnader är något som jag inte är så van vid. Det är dock inte svårare än att ta annan estimering ett steg till och fundera på vad timmar, hårdvara, mjukvara etc. kostar samt vilken information du behöver för att få fram dessa uppgifter. Glöm inte bort kostnaden för projektledningen (kontrollera risker, säkra kvalitet etc.).

Fastställa budget

Den totala kostnaden för projektet sammanställs i en budget. Precis som med tidsschemat så föregås budgeten av en riskanalys och den innehåller reserver, såväl beredskap (contingency) som styrning (management). Budgeten har följande nivåer:

• Summa kontrollkontoestimat = Projektestimat
• Projektestimat + Beredskapsreserv = Kostnadsbaseline
• Kostnadsbaseline + Styrningsreserv = Kostnadsbudget

Kontrollera kostnader

Kontrollera kostnader handlar om samma sak som andra kontrollprocesser, d v s mäta kostnader och vidta reaktiva och proaktiva åtgärder för att hålla kostnaderna enligt plan. För att mäta kostnader finns ett antal formler som måste memoreras:

Formlerna förstås lättare med följande enkla exempel:

I det här exemplet är det lätt att se att vi överskridit budgeten eftersom varje aktivitet blivit dyrare än planerat men att vi ligger före i schemat eftersom vi redan påbörjat aktivitet 2. Formlerna hjälper oss dock att åsätta dessa avvikelser värden och tolka dessa. Kanske beror de höga kostnaderna och snabba arbetet på dyr övertid? I exemplet skulle vi i så fall ha "råd" att minska på tempot (utan att missa schemat) för att minska övertiden (och därmed kostnaderna).

Rita har flera bra exempel och övningar på hur dessa formler används och tolkas. Hon har också några bra tumregler för att komma ihåg alla dessa formler:

• Om EV används kommer det först i formeln
• Kostnadsformler använder AC, schemaformler använder PV
• Varianser är EV plus något, index är EV delat med något
• Negativa varianser är dåligt, positiva varianser är bra
• Index under 1 är dåligt, index över 1 är bra

Det här är ett relativt nytt område för mig men blir viktigare och viktigare i takt med att jag måste åsätta mitt testarbete ett konkret värde. Ett sådant exempel är när jag planerat användning av utlokaliserade resurser. Här blir då kostnadsdimensionen särskilt intressant i bedömningen av hur bra testarbetet går och hur lönsamt det är.

8. Quality Management

Kvalitetsstyrning eller Quality Management handlar om att ta fram och följa kvalitetspolicies. Planen sammanställs i en kvalitetsstyrningsplan (Quality Management Plan). Kvalitet definieras som hur väl projektet uppfyller kraven (memorera detta!). Kvalitet handlar alltså inte om att överträffa förväntningarna (så kallad gold plating).

Några viktiga begrepp i sammanhanget är förebyggande framför inspektion (för att slippa dyrare rättningar senare), marginalanalys (vid vilken nivå är kvalitetsåtgärder inte längre lönsamma), ständig förbättring eller kaizen, total kvalitetsstyrning (total Quality Management eller TQM), just in time (inleverans när en vara behövs för att minimera lagertid) samt kostnaden för dålig kvalitet (omarbete, förseningar, moral etc.).

• Initiering: -
• Planering: Planera kvalitet
• Verkställande: Utför kvalitetssäkring
• Uppföljning och Kontroll: Kontrollera kvalitet
• Avslutning: -

Den huvudsakliga skillnaden mellan dessa tre processer är att kvalitetsplanering handlar om att ta fram policies för att få kvalitet, kvalitetssäkring handlar om att följa dessa policies och kvalitetskontroll handlar om att verifiera att resultatet har fått kvalitet.

Kvalitet är ett centralt begrepp i mitt testarbete. Test handlar om mer än att bara testa en färdig produkt, det handlar om att vara med från början och granska att kraven är korrekta och testbara, att designen uppfyller kraven och är genomförbar, att utvecklingen följer designen och god sed samt att testfallen kan spåras hela vägen tillbaka till kraven. Syftet med detta är att hitta felen i den projektfas de uppstår så att de kan rättas till omedelbart. Att upptäcka ett fel i ett krav först under test innebär att man måste börja om från början med krav, design och utveckling.

Planera kvalitet

För att planera kvalitet måste du som projektledare identifiera alla krav på kvalitet i projekt. Det räcker inte med en enkel kravlista utan krav kan komma från flera olika nivåer:

• Externa krav: Omvärldsfaktorer (enterprise environmental factors) såsom branschstandarder
• Interna krav: Organisationsprocesser (organizational process assets) såsom kundens egna kvalitetskrav
• Projektspecifika krav: Tillkommande policies som DU som projektledare anser nödvändiga för projektets kvalitet

Den tredje punkten innebär inte att du ska införa kvalitet till varje pris utan att du ska väga kostnaden för kvalitet (t ex träning) mot kostnaden för dålig kvalitet (t ex omarbete).

I planeringen ingår också att ta fram kontrolldiagram som du sedan kan kontrollera kraven mot. Dessa diagram har specifikationsgränser (av kunden accepterade avvikelser) och kontrollgränser (av projektet accepterade avvikelser, normalt snävare än specifikationsgränserna). En process anses vara bortom kontroll om ett värde faller utanför kontrollgränsen ELLER om värden uppvisar ett icke slumpmässigt mönster. Ett exempel på det senare är "regeln om sju" som säger att sju värden i rad över (eller under) medelvärdet bör undersökas.

Andra viktiga begrepp i sammanhanget är benchmarking (jämförelse med andra projekt för att hitta förbättringsmöjligheter), experimentell design (statistisk analys av enskilda variablers påverkan på kvaliteten), statistiska stickprov (om inte hela urvalet kan granskas) och flödesscheman (för att hitta potentiella kvalitetsproblem).

Processen Planera kvalitet resulterar i följande leverabler:

• Kvalitetsstyrningsplan (Quality Management Plan): Kvalitetspolicies, kvalitetsansvariga, kvalitetsrapporter etc.
• Kvalitetsmätetal (Quality Metrics): Mätetal för kvalitetskontroll, t ex antal förändringar, antal upptäckta fel etc.
• Checklistor: Listor på steg att utföra, saker att inspektera etc.
• Processförbättringsplan: Plan för hur existerande processer ska förbättras
• Uppdateringar till projektplan och -dokument: Kvalitetsplanering är en interativ process som påverkar andra processer (kostnader för kvalitet påverkar kostnadsstyrningen etc.)

Som testledare är jag van vid att ta fram policies för mitt testprojekts kvalitet och jag arbetar också med acceptanskriterier som testresultaten utvärderas mot.

Utför kvalitetssäkring

Som ovan nämnts handlar kvalitetssäkring om att säkra att planerade kvalitetspolicies följs. Ett exempel på detta är en kvalitetsrevision där parter utanför projektet utför granskningen. En annan viktig uppgift är processförbättring, t ex genom processanalyser. En väl genomförd kvalitetssäkring leder till rekommenderade förändringar och uppdateringar av projektprocesser och -dokument.

Kvalitetsrevisioner förekommer också på Accenture där företaget säkrar att vi konsulter följer processer och standarder enligt vår leveransmetodologi. Jag har varit med om ett par sådana och de har alltid gått snabbt (kanske lite för snabbt eftersom jag hade uppskattat tips om hur jag kan få ännu bättre kvalitet i mitt arbete).

Kontrollera kvalitet

Som ovan nämnts handlar kvalitetskontroll om att verifiera kvaliteten på leverablerna. För att tolka kvalitetsdata används statistiska begrepp som ömsesidigt uteslutande (utfall som inte kan förekomma samtidigt, t ex krona och klave), sannolikhet, normalfördelning, statistiskt oberoende (utfall som inte kan påverka varandra, t ex utfallet på en tärning) och standardavvikelse (avvikelse från medelvärde). Ett annat namn för standardavvikelse är sigma som ett uttryck för de kvalitetskontrollnivåer ett företag vill uppnå. Sigma 2 innebär att 95 % av utfallen är inom kvalitetskontrollnivåerna, sigma 3 99,7 % och sigma 6 nära 100 %.

Du behöver inte vara expert på statistik för att klara certifieringsexamen utan det räcker med att känna till dessa begrepp.

Vidare finns det sju grundläggande verktyg för att mäta kvalitet (också kallade Ishikawa's sju verktyg):

• Orsak och verkan (fiskben, Ishikawa): Nedbrytning av uppkomna problem i möjliga orsaker
• Flödesdiagram: Moment i en process från start till slut (för att identifiera var problem kan ha uppkommit, se Planera kvalitet)
• Histogram: Stapeldiagram utan rangordning
• Paretodiagram: Stapeldiagram rangordnade med vanligaste utfallet först (för att identifiera de mest kritiska problemen)
• Trenddiagram (Run Chart): Visar utfall över tiden (för att identifiera trender och mönster)
• Regressionsdiagram (Scatter Diagram): Visar två variablers utfall på en x- och en y-axel (för att identifiera samband)
• Kontrolldiagram: Visar utfall, specifikationsgränser och kontrollgränser (för att identifiera utfall bortom acceptabla gränser, se Planera kvalitet)

Observera att flera verktyg förekommer också i planeringen av kvalitet. Som planeringsverktyg används de för att blicka framåt och förebygga problem. Som kontrollverktyg används de för att blicka bakåt och fånga upp problem som trots det uppkommit.

En väl genomförd kvalitetskontroll ger leverabler av kvalitet samt, precis som kvalitetssäkring, rekommenderade förändringar och uppdateringar av projektprocesser och -dokument.

Också detta område är jag bekant med då test handlar just om att säkra leverablernas kvalitet. Det räcker heller inte att bara fånga upp problemen, jag måste också gå till roten med dem och vidta lämpliga åtgärder. Det kan handla om att öka testansträngningarna inom områden med många fel eller till och med avbryta testerna och rekommendera att de föregående faser där felen uppstått (krav, design etc.) rättas. Däremot arbetar jag sällan med acceptabla nivåer. Ett bra testfall ska ha tydliga kriterier för vad som är godkänt och underkänt. Acceptabla nivåer är vanligare i t ex produktion där slutproudkterna har mer flytande kriterier (t ex viktintervaler).

9. Human Resource Management

Personalstyrning eller Human Resource Management handlar om att planera sin personals arbete och förbättra deras arbetsinsats. Motivationsteorier och belöningssystem är därför viktiga begrepp i sammanhanget.

En viktig aspekt av personalstyrning är att förstå och/eller definiera de olika aktörernas uppgifter i projektet.

Två mer perifera men också viktiga roller är portföljledaren (säkrar att portföljens projekt ger värde till organisationen) och programledaren (säkrar att programmens projekt stöder organisationens strategiska mål).

• Initiering: -
• Planering: Ta fram personalplan (Human Resource Plan)
• Verkställande: Sätt ihop projektteam, Utveckla projektteam, Led projektteam
• Uppföljning och Kontroll: -
• Avslutning: -

Ta fram personalplan

En personalplan definierar teammedlemmarnas roller och ansvar i projektorganisationen. I detta ingår inte bara att färdigställa arbetspaket uatan också att stödja risk-, kvalitets- och/eller projektledningsaktiviteter. Såväl omvärldsfaktorer som organisationsprocesser är viktiga ingående leverabler i arbetet. Roller och ansvar i projektorganisationen kan sammanfattas på olika sätt:

• Ansvarsmatris (Responsibility Assignment Matrix): Anger för varje aktivitet vem som är primärt ansvarig och vem som är sekundärt ansvarig
• RACI-matris (Responsible, Accountable, Consult, Inform): Anger för varje aktivitet vem som utför (Responsible), ansvarar (Accountable), konsulteras (Consult) och informeras (Inform)
• Organisationsnedbrytning (Organizational Breakdown Structure): Arbete nedbruter på avdelning
• Resursnedbrytning (Resource Breakdown Structure): Arbete nedbrutet på resurstyp
• Positionsbeskrivning (Position Description): Arbetsbeskrivning för projektarbete

Förutom roller, ansvar och projektorganisation omfattar personalplanen också personalplanering:

• Resurstillsättning: Varifrån kommer resurserna?
• Resurskalender: När används resurserna (åskådliggörs t ex i ett resurshistogram)?
• Träning: Vilken träning behöver resurserna?
• Belöningssystem: Hur ska resurserna motiveras, utvärderas och belönas?
• Regler och säkerhet: Hur uppfylls personalregler och säkerhetskrav?

Att motivera personalen är en av de viktigaste men mest åsidosatta aspekterna av personalplanering. Ett väl genomfört motiveringsarbete kan dock bidra inte bara till teammedlemmarnas tillfredsställelse utan också din egen som (projekt-)ledare. Hur motiverar man då teammedlemmar om man inte, som så ofta är fallet, är deras direkte chef? Ett bra tips är att fråga varje teammedlem vad de har för förväntningar på projektet, såväl det professionella planet som det personliga planet. På så vis kan man t ex styra deras uppgifter mot särskilt intressanta teknikområden eller underlätta för dem att gå tidigare vissa dagar. Jag under mina många år som konsult ALDRIG fått den frågan men har börjat ställa den själv till mina teammedlemmar. Min erfarenhet är att teammedlemmarna inte har så mycket att säga i början av projektet då scheman och arbetsuppgifter ännu är oklara och att frågan därför bör ställas löpande. Rita har också "amerikanska" förslag, såsom att utse månadens teammedlem, men det är sådant jag tror kan upplevas som lite fånigt i en svensk kultur.

Sätt ihop projektteam

Att sätta ihop ett projektteam handlar om att under projektets verkställande ta in teammedlemmar i rätt tid och på rätt plats. Observera att vissa teammedlemmar deltar redan från planeringen men att det slutliga teamet deltar först i verkställandet. Viktiga saker att tänka på för dig som projektledare är att identifiera dem som är "förbokade" till projektet, att förhandla för andra resurser samt att avgöra om de ska tas internt, nyanställas eller kontrakteras utifrån (outsourcing). Du måste också känna till och beakta begrepp som virtuella team (teammedlemmar som inte träffas utan arbetar på distans) och haloeffekt (risken att en persons styrkor inom ett område anses göra honom lämplig för andra områden).

I konsultbranschen är detta ett standardförfarande. Tillgängliga resurser utvärderas i en så kallad staffingprocess och om kritiska resurser saknas anlitas tredjepartsleverantörer. Däremot är det ovanligt att någon anställs för en specifik framtida projektroll.

Utveckla projektteam

Att utveckla ett projektteam handlar om att med mjuka ledarskapsmetoder skapa en bra arbetsatmosfär. Några nyckelord är ärlighet, öppenhet, tillit, erkännande och empati. Målet är minskad personalomsättning, ökad individuell kunskap och förbättrat teamarbete. Rita listar ett antal metoder för att uppnå detta:

• Teambyggande: Aktiviteter för att få individuella personer att arbeta som ett team. Denna utveckling anses genomgå fem faser.
• Formering (Forming): Medlemmar sammanförs i ett team
• Storm (Storming): Teammedlemmarna har meningsskiljaktigheter när de börjar arbeta med varandra
• Normering (Norming): Teammedlemmarna börjar bygga relationer
• Prestation (Performing): Teammedlemmarna arbetar effektivt tillsammans och projektledaren kan fokusera på individuell utveckling
• Ajournering (Adjourning): Projektet avslutas och teamet upplöses
• Träning: Träning som hjälper teammedlemmarna att utföra sitt arbete.
• Regler: Klargöranden av vad som är acceptabelt och oacceptabelt projektbeteende, t ex regler kring hur och till vem saker kommuniceras.
• Samlokalisering ("War Room"): Sammanförande av teamet till en plats för att förbättra kommunikationen.
• Belöningssystem: System för att uppmärksamma och belöna bra arbete.
• Utvärdering: Formell och informell utvärdering av teamets och enskilda medlemmars arbete.

Det här är en lång lista och mycket av det borde vara självklart i de flesta projekt. Tvyärr stannar det ofta på papperet och jag har sett många exempel där utvecklingen åsidosatts eller rent av glömts bort. Nyckeln till framgångsrik utveckling är enligt min uppfattning projektledarens engagemang och aktiviteternas spontana natur.

Ta första punkten som exempel. Teambyggande är något som projektledaren ofta delegerar helt. Jag har i början av min karriär fått sådana uppgifter och jag minns hur jag och en kollega en gång planerade vad VI tyckte var roligt. Resultatet blev friluftsaktiviteter och tältövernattning i "scoutanda". Roligt för unga killar men inte lika roligt för t ex kvinnor med andra hygieniska behov. (Jag får väl skylla på att jag var singel på den tiden.) Lyckligtvis uppmärksammades detta så att aktiviteten kunde anpassas men det visar bara på vikten av att någon med helhetssyn engagerar sig i teambyggandet. Ett liknande exempel är de aktiviteter jag deltar i idag, som tyvärr fokuserar mer på sprit och musik än på mat och samvaro. (Men här får jag kanske skylla på att jag börjar bli gammal.)

Vad träning beträffar så har jag ofta stått "på andra sidan" och som ansvarig för introduktionsutbildningar sett hur projektledare vägrat släppa sina nyanställda konsulter. Någon motivering till varför den nyanställde inte skulle behöva en utbildning i grundläggande projektmetodik har jag aldrig fått.

Regler är ytterligare ett område med många fallgropar. Regler behövs men om projektledaren själv skriver dem så kan de uppfattas som pekpinnar. Engagera hellre hela teamet - det är ju trots allt deras arbetsmiljö det handlar om.

Belöningar och utvärderingar slutligen är ofta formaliserat på konsultfirmor. Glöm för all del inte bort den informella ryggdunkningen. Den anställde ska inte behöva vänta till projektets slut på att få veta om arbetet varit bra eller dåligt.

Led projektteam

Att leda ett projektteam handlar om att uppmuntra bra kommunikation, observera och loggföra vad som händer samt aktivt leta upp och lösa konflikter som teammedlemmarna inte kan lösa själva. Följande koncept är viktiga att känna till i sammanhanget:

• Observation och konversation: Nöj dig inte med statusrapporter utan träffa dina projektmedlemmar och prata med dem
• Projektutvärdering: Chefers utvärdering av teammedlemmarnas arbete i projektet (inte att förväxla med teamutvärdering - projektledarens utvärdering av teamet som helhet)
• Loggföring (Issue Log): Loggföring av personers problem, orsaker, följder och hur de slutligen löstes
• Projektledarens makt: Olika typer av makt som projektledaren kan utöva gentemot sina teammedlemmar, här listade i den ordning de bör användas:
• Expert: Informell makt som grundar sig i din kunskap och/eller erfarenhet
• Belöning: Formell makt där du kan belöna bra arbete
• Referens: Informell makt baserad på din respekt
• Formell: Formell makt där du genom din position kan genomdriva din vilja
• Bestraffning: Formell makt där du kan bestraffa dåligt arbete
• Ledarskapsstil: Olika typer av ledarskapsstil som kan behöva anpassas efter situationen, här några exempel:
• Dirigerande: Säg åt andra vad de ska göra (ofta bra under planering)
• Faciliterande: Samordna andras arbete (ofta bra under verkställande)
• Konsultativ: Bottom-up-ansats där projektledaren samlar in andras uppfattningar
• Byråkratisk: Exakta processer för att hantera kritiska moment
• Laissez-faire: "Tillåt att handla", projektledaren låter (kvalificerade) teammedlemmar arbeta på egen hand
• Influerande: Fokus på teamarbete, teambyggande och teambeslut
• Konflikthantering: Meningsskiljaktigheter som löses av de inblandade genom öppenhet, här listade efter de vanligaste orsakerna (memorera detta!):
• Schema
• Projektprioriteringar
• Resurser
• Tekniska uppfattningar
• Administrativa procedurer
• Kostnader
• Personlighet
• Konfliktlösning: Metoder för att lösa problem:
• Konfrontering eller problemlösning: Lös grundproblemet så att alla parter blir nöjda (ofta det bästa alternativet)
• Kompromiss: Hitta lösningar som båda parter kan acceptera (sämre än konfrontering)
• Undvikande: Skjut upp problemet (sällan det bästa alternativet)
• Utjämning: Fokusera på områden där parterna är överens
• Samarbete: Sammanför olika uppfattningar för att nå konsensus
• Tvång: Genomdriv en åsikt på bekostnad av en annan (ofta det sämsta alternativet)

Ett sista viktigt begrepp att känna till är motivationsteori för att förstå vad det är som motiverar personalen. Följande teorier listas av Rita:

• X- och Y-teorin (McGregor): X-människor måste övervakas medan Y-mäniskor kan arbeta självständigt
• Behovspyramid (Maslow): Människor har en hierarki av behov där behov måste tillfredsställas i rätt ordning (fysiska, säkerhetsmässiga, sociala, beröm och självförkligande)
• Behovsteori (McClelland): Människor motiveras av framgång (achievement), samarbete (affiliation) eller makt (power)
• Hygienfaktorer (Herzberg): Hygienfaktorer (lön, arbetsförhållanden etc.) har negativ påverkan på motivationen och motivationsfaktorer positiv (uppskattning, självförverkligande)

Puh! Det här var långa listor av begrepp som förhoppningsvis är bekanta från grundskolan. Du behöver inte kunna räkna upp dem men väl känna till dem till certifieringsexamen där de kan dyka upp som svarsalternativ. Det kan också förekomma "falska" teorier som svarsalternativ så om du ser en teori som du inte känner till så är det alternativet antagligen fel. Till det vardagliga projektledningsarbetet bidrar de dock inte så mycket. Här räcker det med sunt förnuft tillsammans med (självklara?) insikten att människor är olika. Det viktiga är att du verkligen tar dig tid till att motivera dina teammedlemmar. Det är trots allt de som ska göra jobbet, du ska "bara" underlätta för dem att göra sitt jobb.

10. Communications Management

Kommunikationsstyrning eller Communications Management handlar om att planera, strukturera och kontrollera all kommunikation i projektet. Detta är viktigt då 90 % av en projektledares tid ägnas åt kommunikation. För att förstå begreppet kommunikationsstyrning måste du förstå begreppet intressenter. Som tidigare nämnts så är intressenter alla de som kan påverka eller påverkas av projektet. För att projektet ska nå sina mål måste därför du som projektledare arbeta med intressenter enligt följande:

1. Identifiera SAMTLIGA: Sent identifierade intressenter leder till sent identifierade krav
2. Bestäm SAMTLIGAS krav: Sent identifierade krav leder till dyra förändringar
3. Bestäm förväntningar: Förväntningar på vad projektet ger och hur det påverkar det dagliga arbetet kan leda till krav och/eller begränsningar
4. Bestäm intresse: Några kan vara intresserade av att delta medan andra hellre undviker projektet
5. Bestäm inflytande: Inflytande ger makt över projektet, något som kan påverka det både positivt och negativt beroende på deras förväntningar och intresse
6. Planera kommunikation: Planera hur de ska hållas informerade och hur information ska insamlas från dem
7. Kommunicera med dem: Kommunicera med dem på lämpligt sätt
8. Hantera förväntningar och inflytande: Hantera intressenter löpande under hela projektet

Dessa uppgifter behandlas i följande processer:

• Initiering: Identifiera intressenter
• Planering: Planera kommunikation
• Verkställande: Distribuera information och Hantera intressenters förväntningar
• Uppföljning och Kontroll: Rapportera prestationer
• Avslutning: -

Identifiera intressenter

Intressenter kan identifieras med följande verktyg:

• Intressentanalys: Identifiera intressenter genom initiala intressentlistor och tekniker som intervjuer eller brainstorming och analysera sedan deras inflytande och sätt att hantera inflytandet
• Intressentregister: Sammanställ intressentinformation i ett register som anger detaljer, krav, förväntningar, inflytande och roll i projektet
• Strategi för hantering av intressenter: Anpassa hantering till enskilda intressenter eller grupper av intressenter (tät kommunikation, involvering i projektet, detaljerade rapporter etc.)

Att intressenter är viktigt att ha med i planeringen förnekar nog ingen. Frågan är bara hur det ska genomföras i praktiken. Intressenter är trots allt bara människor och de kan såväl byta åsikter som bytas ut helt. Jag har varit på projekt där intressenter som påverkats negativt (därför att de ser sina arbetsuppgifter försvinna) effektivt lyckats blockera aktiviteter. Jag har också sett "ketchupeffekter" när intressenterna i fråga lämnar projektet och aktiviteterna plötsligt går snabbare än väntat. Ett intressentregister är således inte någonting som ska sammanställas enbart under planeringen utan löpande uppdateras under projektets gång.

Planera kommunikation

Nyckeln till bra kommunikation är att den ska vara adekvat (endast nödvändig information) och effektiv (rätt format i rätt tid). Vidare måste den vara både intern (projektteamet) och extern (resten av organisationen, andra projekt), både horisontell (till personer på samma nivå) och vertikal (ledning och lägre positioner). Rita skiljer på följande fyra kommunikationstyper och det är viktigt att vilka typer som krävs i olika situationer:

En annan viktig aspekt att beakta är de "störningar" som hindrar kommunikation och lyssnande. Över hälften av kommunikationen är icke verbal (kroppsspråk etc.) och även paralingvisk kommunikation (ton och röstläge) påverkar hur meddelanden uppfattas. Lösningen stavas effektiv kommunikation (be om återkoppling) och aktivt lyssnande (bekräfta att du förstår eller be om klargörande). Skilj också på interaktiv kommunikation (både sändare och mottagare deltar, t ex möten), "push-kommunikation" (endast sändaren agerar, t ex statusrapporter) och "pull-kommunikation" (endast mottagaren agerar, t ex dokumentbibliotek).

Slutligen en formel att memorera: Antalet kommunikationskanaler beräknas som (N * (N - 1)) / 2 där N är antalet aktörer. Två aktörer har således bara en kommunikationskanal (2 * 1 / 2) men om en ytterligare två aktörer tillkommer får vi plötsligt sex gånger så många kommunikationskanaler (4 * 3 / 2).

"Störningar" i samband med kommunikation är något jag ofta måste ta hänsyn till, inte minst i kontakter med utlokaliserade resurser från våra kontor i Indien. Jag är ofta hänvisad till kommunikationsmedel som inte förmedlar icke-verbal kommunikation (e-post, telefon etc.) och störningar i form av andra kulturella skillnader tillkommer. Det finns många som hävdar att man måste arbeta hårt med effektiv kommunikation för att komma förbi indiers tendens att säga "ja" till allting. Jag tyckte själv så i början men ju mer jag arbetar med indier, desto mer tycker jag att det är ett lite för snävt, för att inte säga fördomsfullt, synsätt. Viktigare är det i så fall att lära känna personen först under mer avslappnade former innan man går in på den professionella kommunikationen. Eftersom vi arbetar med samma arbetsuppgifter på samma företag så är det ju trots allt mer som förenar oss än som skiljer oss. Lyckligtvis är detta något som anammas mer och mer av konsultföretag och regelbundna personliga möten är idag en självklarhet i utlokaliseringsaffärer.

Distribuera information

Kommunikationsplanen ligger till grund för hur du distribuerar information (se ovan). Kom ihåg nyckelorden adekvat, effektiv, intern, extern, horisontell och vertikal.

Hantera intressenters förväntningar

Intressenters förväntningar kan som ovan nämnts leda till krav och/eller begränsningar. Varför ska du då fortsätta hantera förväntningarna under projektet? Svaret är att intressenterna kommer att vara med hela projektet och därmed också deras förväntningar. Genom att ständigt hålla dem informerade, klargöra orealistiska förväntningar och bygga förtroende så kan möjligheter tillvaratas och problem undvikas.

Som testledare är det oerhört viktigt att hantera förväntningar. I acceptanstesterna arbetar jag ju direkt med slutanvändare och är således i deras ögon länken mellan dem och det system de ska använda i sitt dagliga arbete. Jag måste hålla dem informerade om funktioner som inte uppfyller deras förväntningar, kända fel, tillfälliga lösningar etc. - annars kommer de ofrånkomligen att få ett negativt intryck av hela systemet.

Rapportera prestationer

Rapportera prestationer handlar helt enkelt om att samla in information om projektets framåtskridande, analysera den och skicka den till intressenter i rätt tid och med rätt format. Här ingår också att få återkoppling på rapporterna och säkra att projektet fortfarande uppfyller sina mål. Här är några exempel på rapporter:

• Statusrapport: Nuvarande status jämfört med baseline
• Progressrapport: Beskrivning av vad som åstadkommits
• Trendrapport: Projektresultat över tiden
• Prognosrapport: Förutsägelse om framtida projektresultat
• Variansrapport: Jämförelse mellan verkligt resultat och baseline
• Intjänat värde: Nyckeltal såsom Earned Value

De flesta av dessa rapporter kan fås som standardrapporter i testverktyg. Se till att du lär känna ditt testverktyg så att du inte uppfinner hjulet på nytt!

11. Risk Management

Riskstyrning eller Risk Management handlar om att förutse risker och planera för hur de ska bemötas. Målet är att minimera sannolikheten för och verkan av negativa händelser men också att maximera sannolikheten för och möjligheten av positiva händelser. Vid bedömningen av risker måste du ta hänsyn till sannolikhet, möjlig verkan, förväntad tidpunkt och förväntad frekvens. För bedömningen behöver du veta följande:

1. Projektbakgrund: Projektförklaring, lärdomar från andra projekt etc.
2. Organisationsbakgrund: Organisationsprocesser och omvärldsfaktorer
3. Organisationens syn på risk: Risktolerans och riskgränser (acceptabla risknivåer)
4. Projektdetaljer: WBS och estimat
5. Andra aktörer: Team och intressenter
6. Andra planer: Kommunikation, personal och inköp

Riskstyrning hanteras i följande processer (måste memoreras!):

• Initiering: -
• Planering: Planera riskstyrning, Identifiera risker, Utför kvalitativ riskanalys, Utför kvantitativ riskanalys, Planera riskrespons
• Verkställande: Distribuera information och Hantera intressenters förväntningar
• Uppföljning och Kontroll: Följ upp och kontrollera risker
• Avslutning: -

Planera riskstyrning

Planeringen av riskstyrningen engagerar alla aktörer (projektledare, sponsor, team, kund och andra intressenter) och utmynnar i en riskstyrningsplan (Risk Management Plan):

• Metodologi: Hur ska riskstyrning genomföras?
• Roller och ansvar: Vem gör vad?
• Budget: Vad kostar riskstyrningen?
• Tidpunkt: När utförs riskstyrningen?
• Riskkategorier: Hur ska riskerna kategoriseras?
• Generella: Externa (lag, marknad etc.), interna (tid, kostnad etc.), tekniska (teknologiförändringar) och oförutsägbara
• Specifika: Relaterade till kund, projektledning, omvärldsfaktorer etc.
• Källrelaterade: Schema, kostnad, kvalitet, scope, resurser, kundtillfredsställelse etc.
• Affärsrisker (vinst eller förlust) och rena eller ej försäkringsbara risker (endast förlust)
• Definitioner av sannolikhet och verkan: Standardisera tolkningar så att jämförelser kan göras
• Intressenters tolerans: Låg risktolerans fordrar högre riskranking och tvärtom
• Rapportformat: Vilka rapporter behövs för att rapportera riskstyrningen?
• Spårning: Hur ska riskstyrningen granskas och dokumenteras?

Identifiera risker

Identifiera risker utförs av alla på projektet. Processen börjar så tidigt som möjligt men risker kan också identifieras senare i projektet, t ex under integrerad förändringskontroll. Följande är några verktyg och tekniker som används:

• Dokumentgranskningar
• Informationsinsamling (brainstorming, delfiteknik, intervjuer, analys av grundorsaken)
• SWOT-analys (Strengths, Weaknesses, Opportunities, Threats)
• Checklistor
• Analys av antaganden
• Diagramanalyser (flödesscheman etc.)

Den viktigaste leverabeln från denna process är riskregistret. Riskregistret listar risker, möjliga svar, grundorsaker och riskkategorier och uppdateras löpande under riskstyrningen.

Det skiljer en del mellan PMI:s syn på riskstyrning och den riskstyrning som jag möter i min vardag. PMI utgår ju från en perfekt värld där projektet är planerat in i minsta detalj och alla avvikelser utgör risker. Det vanliga är dock att projektet definieras under projektets gång och att riskstyrning handlar mer om beredskap än om förebyggande. Visst identifierar jag risker i mina testprojekt (vanligtvis relaterade till förseningar i ingående leverabler och brister i testmiljön som jag inte har något inflytande över) men de landar ofta bara i ett riskkapitel och uppmärksammas sällan utanför mitt projekt. Å andra sidan får jag ofta höra att jag hanterar alla problem smidigt så även om jag inte aktivt arbetar med ett riskregister så har jag ändå riskerna i bakhuvudet. Kanske bör jag använda riskregistret som ett verktyg för att öka förståelsen för "mina" risker och på så vis jobba mer proaktivt? Till certifieringsexamen är det viktigt att du tänker på riskstyrning som en proaktiv process, INTE en reaktiv.

Utför kvalitativ och kvantitativ riskanalys

När du har listat riskerna i ditt riskregister är det dags att analysera dem. Den kvalitativa analysen är subjektiv och baseras på sannolikhet och verkan enligt standardiserade definitioner. Informationen sammanfattas i en sannolikhets- och verkansmatris (Probability and Impact Matrix). Nästa steg är att utvärdera riskernas datakvalitet (hur pålitlig och förstådd är informationen?), kategorisera dem (hur relaterar riskerna till varandra?) samt bedöma hur brådskande de är (vilka bör åtgärdas först?). Icke kritiska risker flyttas till en observationslista (watchlist) och senare uppföljning.

Utför kvantitativ riskanalys

Den kvantitativa riskanalysen är, till skillnad från den kvalitativa, objektiv och syftar till att omvandla de kvalitativa uppskattningarna till konkreta tal (kronor, timmar etc.). Följande är några metoder för att kvantifiera risker:

• Intervjuer
• Kostnads- och tidsestimat
• Historiska data
• Expertutlåtanden
• Förväntat monetärt värde (enkelt beräknat genom sannolikheten multiplicerad med kostnaden av verkan)
• Monte Carlo-analys (datorsimulering av möjliga utfall)
• Beslutsträd (visar förväntat monetärt värde av ömsesidigt uteslutande och gemensamt uttömmande alternativ)

Ett enkelt exempel på ett beslutsträd är ett val mellan att fram en prototyp och att inte göra det. Du kan bara göra det ena eller det andra så alternativen är ömsesidigt uteslutande och det finns inga andra alternativ så de är gemensamt uttömmande. Anta att prototypen kostar 100 000 kr och ett misslyckande 1 000 000 kr. Om sannolikheten för ett misslyckande är 10 % med prototyp och 30 % utan så får vi följande förväntade monetära värden av de två besluten:

• Med prototyp: 100 000 kr + 10 % av 1 000 000 kr = 200 000 kr
• Utan prototyp: 0 kr + 30 % av 1 000 000 kr = 300 000 kr

Beslutsträdet visar alltså att det är bäst att ta fram en prototyp då den förväntade kostnaden är lägre.

Utöver en uppdatering av riskregistret och konkreta värderingar av riskerna så får du också en första uppskattning av behovet av reserver för oförutsedd tid och oförutsedda kostnader (förebyggande reserver eller contingency reserves för kända, styrning eller management reserves för okända).

Att kvantifiera risker låter bra i teorin men till och med Rita att det är något som inte nödvändigtvis förekommer på projekt. Många estimeringsmodeller anger helt enkelt en schablonmässig procent av totaltiden/-kostnaden som contingency. Visst skulle det vara bra att kunna peka på det konkreta värdet av ett test men att beräkna det skulle helt enkelt ta mer tid än att helt enkelt utföra testet. Jag nöjer mig därför med att känna till syftet med kvalitativa och kvantitativa analyser till certifieringsexamen.

Planera riskrespons

Riskrespons handlar helt enkelt om att för varje risk planera följande:

1. Eliminera hot och säkra möjligheter
2. Minimera sannolikheten för hot och maximera sannolikheten för möjligheter
3. Agera om risken inträffar (contingency plan)
4. Agera om riskresponsen inte är effektiv (fallback plan)

De två sistnämnda alternativen används för så kallade residuala risker, d v s risker som återstår efter riskresponsplaneringen. De ska inte förväxlas med sekundära risker, d v s nya risker som uppstår när en risk hanteras.

Kom ihåg att certifieringsexamen förutsätter en perfekt värld där alla risker är kända och där du har planer för var och en av dem. Riskstyrning handlar således inte om att hantera risker när de väl inträffat utan att förhindra att de inträffar över huvud taget.

Strategierna för riskrespons kan kategoriseras enligt följande:

Prototypen i exemplet ovan är ett exempel på en mildrande strategi medan försäkringar är exempel på överförande strategier. Oavsett val så måste strategi ommuniceras till ledning, intressenter och sponsorer. Riskregistret måste också uppdateras med riskutlösare (risk triggers) som indikerar när riskresponser måste vidtas och riskresponsägare som ansvarar för att agera på risken. Slutligen måste behovet av reserver fastställas.

Följ upp och kontrollera risker

Följa upp och kontrollera risker innebär INTE att du löser problem OM de inträffar utan att du använder din riskstyrningsplan för att hantera risker NÄR de kommer. Det gör du genom aktiviter som bevaka riskutlösare, utvärdera och uppdatera riskstyrningsplanen, identifiera eventuella nya risker och ta fram nya riskresponser, samla in och kommunicera riskstatus samt rekommendera och utvärdera korrektiva åtgärder. Ett bra forum för utvärdering av risker och riskresponser är statusmöten. Enligt PMI ska statusmöten användas för detta och INTE för att varje teammedlem ska behöva lyssna på andra teammedlemmars status. Riskrevisioner kan också användas för att utvärdera riskstyrningen. Däremot är oplanerade svar på inträffade risker (workarounds) ett tecken på dålig riskstyrning och likaså användning av reserver för andra ändamål än de som reserverna avsattes för.

Som tidigare nämnts så är detta en ideal värld som inte nödvändigtvis överensstämmer med din egen vardag. Läs därför noga igenom Ritas många bra exempel på riskstyrning enligt PMI och utgå från dem när du besvarar frågor i certifieringsexamen.

12. Procurement Management

Inköpsstyrning eller Procurement Management handlar om att bistå vid inköpsavtal, läsa och förstå projektets inköpskontrakt samt hantera dem. Inköpsstyrning intar ett mycket amerikanskt perspektiv, d v s om någonting inte är skrivet så kommer det heller inte att utföras. Rita listar följande tricks för att besvara frågor på certifieringsexamen:

• Kontrakt är formella
• Alla produkt- och projektkrav måste specifikt tas upp i kontraktet
• Saker som inte är upptagna i kontraktet kan bara göras genom formella förändringsbegäran
• Saker som är upptagna i kontraktet måste göras eller tas bort genom formella förändringsbegäran
• Förändringsbegäran och godkännanden måste vara skriftliga
• Kontrakt minskar projektrisker
• Myndigheter har ofta domstolsklausuler för att hantera oenigheter

Som projektledare behöver du inte hantera kontraktsformalia (det gör den centrala inköpsavdelningen eller den tillsatte inköpschefen). Däremot måste du bevaka projektets intressen och se till att allt du behöver tas upp i kontraktet. Du måste också utnyttja inköpen fullt ut för att minska projektets risker. Slutligen är det ditt ansvar att kontrollera att kontraktsåtagandena uppfylls, både säljarens och projektets. Det sistnämnda kan t ex syfta på rapporter och annat som säljaren har rätt till.

Inköpsstyrning är egentligen inte svårt och som civilekonom har jag tillägnat mig teorin redan i mina studier. Däremot är det sällan jag som testledare har något inflytande över inköpet. Jag får i stället föreställa mig hur mycket lättare vissa saker hade gått om jag hade haft inflytande. Som exempel jobbar jag ofta med konsulter från andra företag. I normalfallet går det bra men det händer att dessa konsulter inte alls vill samarbeta. I sådana lägen hade det varit bra att ha inflytande över kontraktet eller åtminstone veta hur det ser ut. Tyvärr är detta inte möjligt då konsulterna tillsatts av kunden själv och jag har därför inget val än att försöka hitta vägar runt samarbetsproblemet (och ta upp det som en risk).

Inköpsstyrningen består av följande processer:

• Initiering: -
• Planering: Planera inköp
• Verkställande: Utför inköp
• Uppföljning och Kontroll: Administrera inköp
• Avslutning: Avsluta inköp

Planera inköp

Inköpsplaneringen handlar om att bestämma vad som behöver införskaffas, hur och från vem. Följande moment ingår i processen:

• "Gör eller köp"-analys: Analysera om det är bäst att köpa arbetet eller att utföra det själv
• Inköpsstyrningsplan (Procurement Management Plan): Process för planering, verkställande och kontroll av inköp
• Inköpsbeskrivning (Procurement Statement of Work): Nedbrytning och specificering av arbete som ska köpas in
• Förfrågning (Procurement Documents: Offertförfrågan (Request for Proposal eller RFP), Anbudsförfrågan (Invitation for Bid eller IFB), Prisförfrågan (Request for Quotation eller RFQ) och Informationsförfrågan (Request for Information eller RFI)
• Urvalskriterier: Specificerar behov (pris, kompetens, kvalitet etc.)
• Kontraktstyp:
• Fastpris: Fast pris för hela arbetet (säljaren bär risken för fördyringar, inhämtas genom IFB)
• Bonus (Incentive Fee): Säljaren får bonus enligt specificerade kriterier
• Belöning (Award Fee): Säljaren får belöning som portioneras ut enligt specificerade kriterier
• Indexering (Economic Price Adjustment): Fastpriset kan justeras enligt specificerade index
• Tid och material: Pris per timme eller enhet (köparen bär viss risk för fördyringar, inhämtas genom RFQ)
• Kostnadsredovisning: Ersättning för kostnader (köparen bär stor risk för fördyringar, inhämtas genom RFP)
• Kostnad (Cost Contract): Säljaren gör inget påslag på kostnaden
• Kostnad med rörligt påslag (Cost Plus Fee): Säljaren gör påslag på kostnaden
• Kostnad med fast påslag (Cost Plus Fixed Fee): Säljaren gör ett fast påslag på totalkostnaden
• Kostnadsbonus (Cost Plus Incentive Fee): Säljaren gör inget påslag men kan få bonus enligt specificerade kriterier
• Kostnadsbelöning (Cost Plus Award Fee): Säljaren gör inget påslag men kan få belöning utportionerad enligt specificerade kriterier
• Kontraktsvillkor: Specificerar acceptans, kontaktpersoner, tvisteförfarande, konfidentialitet, bonus, fakturering, betalning, rapportering, garantier etc.

Till certifieringsexamen behöver du förstå i vilka lägen som de olika kontraktsalternativen är bäst så gå igenom Ritas exempel noga. Om du som köpare har dålig kunskap om de förväntade kostnaderna är fastpris att föredra medan kostnadsredovisning kräver att du har full kontroll över kostnaderna (annars har säljaren inget motiv till att hålla dem nere). I konsultbranschen är tid och material den vanligaste kontraktstypen, något som kräver att köparen kontrollerar det arbete som utförs eftersom säljaren tjänar pengar på varje timme eller enhet.

Du behöver också kunna beräkna de olika kontraktsalternativen. Anta t ex att ett kontrakt löper med fastpris med bonus. Köparen har en målkostnad på 210 000 kr och ett målpåslag på 25 000 kr, vilket summerar till ett målpris på 235 000 kr. Köparen och säljaren har en överenskommen delningskvot på 80/20 på eventuella kostnadsbesparingar. Om kostnaderna stannar på 200 000 kr har säljaren rätt till 20 % eller 2 000 kr. Totalpriset för köparen blir således 200 000 kr + 25 000 kr + 2 000 kr = 227 000 kr att jämföra med de 235 000 kr som priset skulle ha blivit utan kostnadsbesparingar.

Ett begrepp i sammanhanget är antagandehorisonten eller Point of total assumption (PTA). Det relaterar till fastpriskontrakt med bonus och syftar på den kostnad varvid säljaren bär hela risken för fördyringar. PTA beräknas som (Köparens takpris - Målpris) / Köparens delningskvot + Målkostnad. Anta i exemplet ovan att köparen hade ett takpris på 255 000 kr. PTA blir då ( 255 000 kr - 235 000 kr) / 0,8 + 210 000 kr = 235 000 kr. Vid denna nivå har säljaren överskridit målkostnaden med 25 000 kr. Köparen står då bara för 80 % eller 20 000 kr av denna fördyring och säljaren får alltså totalt 255 000 kr. Även om kostnaden skulle bli högre så får säljaren inte mer än 255 000 kr och bär alltså hela risken för ytterligare fördyringar.

Räkna igenom Ritas exempel och se till att du förstår hur man räknar på detta.

Min största (i kronor räknat) erfarenhet av kontrakt är när vi byggde hus. Eftersom vi hade just dålig kunskap om de förväntade kostnaderna valde vi fastpris. Vi borde dock ha inkluderat noggranna specifikationer på vad som skulle ingå samt viten för att minska risken för att arbetet skulle dra ut på tiden. Å andra sidan misstänkte vi, med all rätt skulle det visa sig, att säljaren skulle kompensera sig för sådana vitesbelopp på bekostnad av husets kvalitet. Tänk gärna i termer av privata stora projekt på certifieringsexamen om du inte har någon erfarenhet av inköp från dina professionella projekt.

Utför inköp

I och med denna process engageras säljarna i inköpsstyrningen. Potentiella säljare kan kontaktas genom allmän annonsering eller utskick endast till kvalificerade säljare (Qualified Seller List). Köparen kan också kalla säljarna till en budkonferens (Bidder Conference) för att säkra att alla får svar på sina frågor.

Säljarna svarar sedan med offerter (Seller Proposal), priser (Price Quote) eller anbud (Bid). Köparen granskar och väljer sedan säljare. Valet kan ske utifrån viktade kriterier, minimikriterier, tidigare arbeten eller presentationer.

Processen avslutas med kontraktsförhandlingar om scope, schema och pris (i den ordningen). Det är också viktigt att lägga grunden till ett bra förhållande till säljaren. Syftet med kontraktet är att definiera roller och ansvar, legalisera förhållandet och mildra eller allokera risker. Särskilt det sistnämnda visar på vikten av att projektledaren deltar i inköpsprocessen!

Administrera inköp

Titeln till trots så handlar administrera inköp inte bara om pappersexercis utan om att kontrollera att båda parter uppfyller kontraktet samt hantera eventuella förändringar. Uppgifterna skiljer sig åt beroende på kontraktstyp:

• Fastpris: Kontrollera scope och kvalitet
• Tid och material: Ge säljaren dagliga direktiv, begär konkreta leverabler och kontrollera nedlagd tid
• Kostnadsredovisning: Granska fakturor, säkerställ att arbetet utförs effektivt, ompröva kostnadsestimat löpande

I administreringen ingår också ett kontraktförändringssystem och hanteras som en del av den integrerade förändringskontrollen. Tänk på att inköpschefen och/eller -avdelningen måste engageras i kontraktsförändringar. Till andra viktiga uppgifter hör granskning av kontraktsutförande, hantering av krav (p g a kontraktsbrott) samt underhållande av ett dokumentsystem för all inköpsdokumentation. Kom ihåg det amerikanska perspektivet om frågor om kontraktstolkning dyker upp: skrivna ord, industripraxis och detaljerade villkor har i regel företräde framför muntliga överenskommelser och avsikter.

Avsluta inköp

Avsluta inköp innebär formell acceptans av leverabler, reglering av åtaganden, slutlig betalning, uppdatering av register samt dokumentering av lärdomar - samma saker som när projekt avslutas. Alla inköp måste vara avslutade innan projektet kan avslutas.

13. Professional and Social Responsibility

Ritas sista kapitel handlar om etik, något som genomsyrar samtliga processer och kunskapsområden. PMI:s etiska kodex (The Code of Ethics and Professional Conduct) handlar om att driva projekt med ansvar, respekt, rättvisa och ärlighet. För dig som projektledare räcker det inte med att känna till orden, du måste också ha auktoritet och integritet att omsätta dem i handling och t ex säga nej till orealistiska projekt.

• Ansvar: Främja företagets intressen, ta uppdrag som du är kvalificerad för, skydda konfidentiell information och rapportera oetiskt beteende
• Respekt: Främja samarbete, respektera kulturella skillnader, var ärlig i förhandlingar, var direkt i konflikthanteringar och påveka inte andra till din fördel
• Rättvisa: Var opartisk, lyfta fram intressekonfliktet, diskriminera inte och använd inte din ställning till din förmån
• Ärlighet: Försök förstå sanningen och var sanningsenlig i all kommunikation

De flesta företag har värderingar som täcker dessa punkter. På Accenture har vi t ex så kallade core values (integrity, stewardship, client value creation, respect for the individual, one global network, best people) som vi förväntas leva upp till i vårt arbete. Ta reda på ditt företags värderingar - de kan vara ett bra stöd om du av någon anledning pressas fatta oetiska beslut.

Grattis! Du har nu nått slutet på den litteratur du behöver studera inför projektledarcertifieringen. Lycka till på tentamen!