Ambitioner är slöseri

februari 20, 2007

Att göra storskalig projektplanering är en favoritsysselsättning bland projektledare. I synnerhet inom större organisationer tar man gärna till en storskalig planering. Problemet med det är att eftersom planeringen är så storskalig väljer man att förenkla världsbilden genom att dela in planen i övergripande faser så att aktiviteterna ska synas i den stora skalan.

Det är frestande att börja med att konstatera att man ska ha en förstudie på 4 veckor sedan har man en designfas på 6 veckor, därpå följer en implementationsfas om 10 veckor och sedan givetvis test (kanske 5 veckor) och slutligen en acceptanstest från kunden om ca. en månad. Allt ser på pappret plötsligt välordnat och fint ut. Genast börjar man arbetet med att resurssätta – ett fint ord som eventuellt bara används inom IT-projekt – man kontaktar konsultleverantörer och för att slimma kostnaderna ser till att folk ska ansluta till projektet exakt efter den plan som man har fastslagit. Exempelvis kommer testarna in efter 20 veckor och jobbar i 5v. Ett par utvecklare behåller man under testarbetet eftersom man vet av erfarenhet att det alltid finns lite buggar att ta hand om då.

In kommer sedan ett gäng duktiga utvecklare som ska vara effektiva och ”köra agilt” (agile software development). De lyckas hyfsat och projektet följer, lustigt nog, den från början utstakade projektplanen.

Men så händer något oväntat. Kunden kan, p.g.a. sin egen administration inte ta emot leveransen enligt plan utan ber leverantören att leverera två månader senare. Lyx! 8 veckor till att leverera kundnytta på!
Här visar dock den, ambitiösa, övergripande planeringen sin svaghet. Resurssättningen var avpassad för en fasindelad utvecklingsplan, den kan man inte bara ändra i. Den givna lösningen att låta utvecklingen fortsätta ett par veckor till fungerar inte eftersom de som ska testa redan är resurssatta för ett annat projekt.

Lösningen på problemet är lika enkel som genial, projektadministratörerna get slaget förlorat och konstaterar att: Vi levererar enligt plan och sedan får ”linjen” driva arbetet vidare.

Vad är det som gör att ”linjen” (linjeverksamheten) mer framgångsrikt kan hantera en sådan situation? Undrar vän av ordning.

Svaret ligger i kontinuerlig (om-)planering. I en linjeverksamhet måste man ha förmågan att ständigt manövrera runt oförutsedda händelser och med kort varsel kunna släppa en ny version av produkten som man underhåller. Därför har linjeverksamheter ofta bättre utvecklade leveransprocedurer som gör att man snabbt och enkelt kan driftsätta det bästa man har. Fungerande kod gör ingen nytta genom att enbart stillatigande placeras versionshanteringssystemet, den ska driftsättas och skapa avsedd nytta.

En rimlig frågeställning, varför behövde inte linjeverksamheten ett test-team? Jo, för att testbehovet är kontinuerligt och alla tekniker i en linjeverksamhet måste kunna ta ansvar för att det som driftsätts är genomtestat. Det driver också utvecklingen av snabba, automatiserade tester som låter människor göra det de är bra på (komplex, adaptiv planering och implementering) respektive låter maskinerna göra det de är bra på (repetetivt, förutsägbart beteende). Det sista resonemanget fungerar eftersom tekniker i regel är bra på att undvika ett aldrig sinande enformigt arbete genom välja att skriva en applikation som utför det arbetet åt dem.

Min vädjan till dagens projektplanerare blir – se på er linjeverksamhet och lär. Ni är inte bättre än dem, de är bättre än er.

Annonser