På tal om projekt ...

I många projekt är testning en av de viktigare aktiviteterna. Det gäller i allra högsta grad produktutvecklings- och IT-projekt.

En viktig framgångsfaktor är när i projektet man påbörjar sitt testarbete. Arbetar man efter en strikt vattenfallsmodell riskerar man att alltför sent fånga upp eventuella problem med testaktiviteterna. Om man till exempel arbetat 1,5 år i ett IT-projekt, och har ett halvår kvar till leverans, och först då inser något av följande har man stora problem:

• De olika testmomenten tar längre tid än planerat
• Utbildningen i testverktygen var otillräcklig
• Bemanningen i testgruppen är otillräcklig avseende kvalitet och/eller mängden resurser
• Prestanda-/skalbarhets-/datasäkerhetstester visar att en annan teknisk arkitektur borde ha valts

Listan kan göras mycket längre. Den viktiga slutsatsen är att testgrupperingen av projektet måste sättas i arbete och produktion så tidigt som möjligt i projektet: för att påverka utvecklingsprocessen, för att tidigast möjligt få till ett bra samarbete och flöde med krav- och utvecklingsteamen, för att det ska finnas tid kvar för att åtgärda eventuella utbildningsbehov, för att undvika att testandet blir en flaskhals på slutet osv. Sist men inte minst är det ett fantastiskt bra sätt att minimera risken för sena besked om stora förseningar i projektet.

Vissa projekt- och utvecklingsmetodiker ”tvingar” igång testandet tidigt och man får automatiskt ett bra stöd. Det gäller t ex projekt som använder systemutvecklingsmetodiken RUP, eller projekt som drivs med agila metoder som Scrum.

Viktigast ur det här perspektivet är såklart inte vilken etikett man har på sin process, utan att man börjar testa tidigt. Hur gör ni i era projekt?

I teorin är alla överens om vikten av att lära av tidigare misstag – och självklart framgångar. Det gäller sjävklart inte bara inom projektarbete. Alla som arbetat i ett kunskapsföretag har säkert varit med om försök att införa någon slags databas där alla löpande antecknar vem som kan vad, vad man jobbade med i sitt senaste uppdrag osv så att alla kan gå in och söka information vid behov. Nästan lika många har nog erfarenheten att sådana satsningar misslyckas och faller platt till marken. Orsakerna är flera:

• De som har mest att tillföra till databasen har oftast minst tid att dokumentera
• Man har ofta inte vanan att söka information där när det gäller att lära sig nya saker, och framförallt inte när det gäller att undvika misstag som man inte är medveten om att man håller på att göra
• Man gör av bara farten så som man gjorde senast

Visst kan tekniska förbättringar göra att det funkar bättre. Till exempel är säkert en Wiki-lösning och indexerade sökningar à la Google mycket bättre än en Excelfil. Men det är ändå inte där skon klämmer tror jag.

Motsvarande svårighet finns inom projektvärlden. PMIs PMBOK pratar på ett abstrakt plan om en så kallad knowledge base som ska uppdateras med all upptänklig information och lessons learned, varje gång projektet uträttat något. Men man får inte mycket hjälp på vägen när det gäller hur detta ska åstadkommas eller hur man på ett effektivt sätt drar nytta av all lagrad information. Följande citat från novembernumret av PMIs tidning PM Network sammanfattar problemet:

“To improve the probability of project success, you need a feedback loop, but in many cases companies are too focused on the next project to document, analyze and learn from what happened on the last one. – Steve Jovanovic, pmFAQtory LLC, Chicago, Illinois, USA”¨

Som så ofta handlar det om organisationer som inte alls försöker – eller som i sin överambition försöker med för mycket på en gång. Och som vanligt kan man komma en mycket lång bit på väg genom att verkligen anstränga sig, men anpassa ambitionen till vad organisationen orkar med att prestera – och återutnyttja. Här är tre enkla förslag till att praktiskt ersätta en allt omfattande knowledge base:

• Ta fram en bra mall för projektutvärdering/slutrapport och stäng inga projekt förrän detta dokument har producerats och godkänts. Slutrapporten ska förstås innehålla slutsatser om vad som gått bra och dåligt, mjuka och hårda faktorer, utfall i förhållande till plan osv. En slutrapport från ett projekt inom ett visst verksamhetsområde blir en självklar läsning för projektledaren för nästa projekt inom samma område.
• Se till att företagets projektprocess/metodik uppdateras med viktiga slutsatser från slutrapporten (men ha inga ambitioner att skapa en databas med samtliga projekts samtliga slutsatser).
• Ge varje projektledare en mentor. Det fanns en anledning till att det gamla skråväsendet hade både lärlingar, mästare och gesäller.

För att ett projekt ska bli effektivt fordras det en lagom mängd administration, oavsett om det är i form av traditionell projektplanering, möten, budgetering etc eller sprintplaneringar och dagliga scrummöten. För lite eller för mycket administration ger sänkt effektivitet – fast av olika skäl. För lite ger otillräcklig kontroll och bristfällig informationsspridning och för mycket administration skapar byråkrati och stjäl tid från produktivt arbete i projektet.

Det finns ett nyckeltal som säger att ca 20% av projekttiden bör vara just administration, i ett traditionellt projekt projektledning, delprojektledning, möten, tidrapportering etc. Jag tycker att detta nyckeltal stämmer förvånansvärt bra på olika sorters projekt av alla storlekar.

Varför finns det en sådan övertro på metoder och processer? Personligen känner jag snarare en oro över att det inte kommer fungera när någon tveklöst påstår att med metodik x eller y så löser vi alla problem. Inte ens när de råkar vara den senaste som alla pratar om.

Det vore så mycket bättre om man kunde betrakta olika metodiker som verktygslådor. Som professionell PL ska man givetvis behärska de flesta verktygen i de flesta verktygslådorna. Vattenfallsmetoden lär oss att tänka först och planera i förväg. RUP sätter t ex fokus på ett iterativt arbetssätt och tidigt säkrad arkitektur. De agila metoderna ger oss bra verktyg för att successivt utveckla produkter som vi inte har möjlighet att specificera på förhand och understryker vikten av samarbete, kontinuerligt lärande och vikten av att själv få planera sitt arbete.

Den PL som bäst förmår att analysera sitt projekts och sin organisations förutsättningar, och sedan använder rätt verktyg (även om de kommer från olika verktygslådor) för att nå målen har stora möjligheter att lyckas. Särskilt om man inser att sammansättningen av verktygen bara är startpunkten till det verkligt viktiga: att få användningen av dem att fungera i projektet. Det sistnämnda uppmärksammades också i Det finns inga snabba genvägar i dagens Computer Sweden.

Avslutningsvis ett citat jag fick med mig hem från en ledarskapskurs en gång: “Om det enda verktyg jag har är en hammare, kommer det mesta att se ut som en spik.”

Det vore intressant att starta en diskussion kring vilket verktyg som är bäst för att ta fram Gantt-scheman. Föredrar du det välkända MS Project med sin rika funktionalitet men också stora risker att navigera fel bland alla inställningar och automatiska omräkningar? Använder du ett lättanvänt men mindre flexibelt alternativ? Papper och penna? Väggen i ett war room? Inget alls?

Här borde det finnas lika många åsikter som när PC vs Mac ska diskuteras …

Trevlig helg till alla!

Så var man hemma i Sverige igen, där i och för sig vädret är mycket bättre än det var i Milano. Seminariet Building a Next-Generation Program Management Office and Portfolio Management var intressant. Framförallt hade det en bra balans mellan den ibland lite för processtunga PMI-standardens syn på PMO och portföljhantering och mjukare, mer verklighetsanpassade inslag kring hur man driver det förändringsarbete som behövs och skapar intresse såväl hos företagsledning som projektledare och andra intressenter. Något som ofta dök upp avseende relationen till projektledarna var freedom with a fence, snarare än processpolis.

Seminariet gav också rika möjligheter till internationella jämförelser då de 30 deltagarna kom från Turkiet, Kuwait, Sverige, Malaysia, Frankrike, Schweiz, Italien, Storbritannien, Portugal, Ryssland, Saudiarabien, Tyskland, Spanien, Tjeckien, Polen och seminarieledaren var indier – sedan 25 år bosatt i USA.

Efter att tidigare ha deltagit på PMIs kongress tycker jag att SeminarsWorld är att föredra. Helt klart ligger vi också efter den internationella utvecklingen avseende PMO och portföljhantering i Sverige – eller med andra ord kommer säkert mycket att hända på området på hemmaplan närmaste åren!