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?

Computer Sweden uppmärksammar på nytt Scrum i sin artikel Nu växer kritiken mot Scrum. Den här gången handlar det om att konsultföretag tjänar pengar på certifieringarna och att Ken Schwaber lämnar ordförandeposten i Scrum Alliance.

Personligen tycker jag det är mer intressant att läsa om tillämpningar av Scrum i stora komplexa projekt där det lättrörliga arbetssättet får slåss med andra prioriteringar som t ex krav på tidigt fastslagen teknisk arkitektur eller mer detaljerad planering inledningsvis som krav inför investeringsbeslut. Hur gjorde man och vad ledde det till?

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.”

Ett projekt som ska pågå i två år har sin första milstolpe efter fyra veckor. Man hinner nästan klart och efter sex veckor kan milstolpen till slut passeras. Visst är det märkligt att många då anser att projektet är två veckor försenat, när man egentligen borde konstatera att projektet hittills dragit över tiden med 50%? Om man har samma precision i resten av planeringen har man kanske ett treårsprojekt framför sig snarare än ett på två år och två veckor …

Exemplet är självklart mycket grovt – men ändå tänkvärt. För det första är det bra med milstolpar för att få tidiga mätbara signaler på hur man ligger till i förhållande till sin tidsplan (oavsett om de kallas milstolpar, beslutspunkter eller fasslut efter en iteration eller sprint). För det andra är det bra att redan från början i ett projekt skapa en mycket stor respekt för varje milstolpe.

Ibland ser man skräckexempel på projekt som passerar milstolpar med restpunkter som man utan större åtgärder tror sig hinna med “senare”. Men risken är ju snarare att nästa fas blir ännu värre – förmodligen blir man lika sen med det ursprungligen planerade arbetet, och dessutom har man alla restpunkter från tidigare faser att ta hänsyn till. En milstolpe med restpunkter bör i stället tas som en mycket allvarlig varningssignal för trovärdigheten i den återstående tidsplanen och en åtgärdsplan bör tas fram av projektet.

Ovanstående handlar mest om sunt förnuft och ledarskap, men det finns även metoder som ger lite process-stöd för tankarna. En sån är Earned Value Management (EVM) eller nuvärdesmetoden som den brukar kallas på svenska.

Så var det dags igen: en ny undersökning som slår fast att bara vart tredje IT-projekt lyckas och att det sett likadant ut i 40 år. I dagens artikel i CS lägger KTH-professorn Torsten Cegrell en stor del av skulden på beställarsidan och alltför omfattande specifikationer med dålig koppling till verksamhetsnyttan som eftersträvas.

Det är svårt att inte hålla med om den kritik som kommer fram och det gör lika ont varje gång som de typiska nybörjarmisstagen görs om. Jag tycker ändå det finns skäl att notera att moderna IT-projekt inte nödvändigtvis bör drivas som beställningar via ett kontrakt där specifikationen är klar vid upphandlingstillfället.

Många projekt, oavsett hur väl verksamhetsnyttan/effektmålen är specificerade, stupar just därför att man trott att det varit möjligt att i detalj kravställa nödvändig funktionalitet i början av projektet. Vissa projekt kräver helt enkelt ett annorlunda angreppssätt och systemutvecklingsmetodiker som RUP (med iterativ detaljering av specifikationen) och olika agila metoder som t ex Scrum har vuxit fram för att möta behoven i den typen av projekt.

Är lösningen då att alltid välja Scrum, eller nästa metodikbuzzword som dyker upp? Absolut inte! Däremot är mycket vunnet om åtminstone en person i styrgruppen, och definitivt projektledaren, har förståelse för styrkan och svagheten i en vattenfallsmodell, styrkan och svagheten i RUP, styrkan och svagheten i agila metoder osv och sedan funderar lite över organisationens mognadsgrad, projektets mål och syfte och anpassar metodiken baserat på lång erfarenhet och med fingertoppskänsla.

Lyckas man med det – och dessutom har en beställare som vet vad han eller hon vill – då går det absolut att förändra de tråkiga siffrorna med två av tre IT-projekt som misslyckas.