För mig som projektledare är det en självklarhet att såväl jag som mitt team har en god relation med vår beställare. Att möta beställarens vision är en utmaning för alla projekt, och med närhet till beställaren blir uppgiften i många fall betydligt rimligare. Varje arbetsplats och projekt har förstås sina förutsättningar, men jag tänkte dela med mig av några knep som kanske kan hjälpa dig på vägen med ditt projekt.
För mig som projektledare är det en självklarhet att såväl jag som mitt team har en god relation med vår beställare. Att möta beställarens vision är en utmaning för alla projekt, och med närhet till beställaren blir uppgiften i många fall betydligt rimligare. Varje arbetsplats och projekt har förstås sina förutsättningar, men jag tänkte dela med mig av några knep som kanske kan hjälpa dig på vägen med ditt projekt.
Pröva ofta
Ju oftare du bygger ihop funktionalitet och visar upp den, ju oftare kan du få feedback på den lösning du valt! Arbeta gärna med prototyper, men glöm inte att prototyper ofta gömmer väsentlig information, som till exempel svarstider och tillgänglighet till data. Demonstrationer vid varje iterations slut erbjuder ofta en god möjlighet till feedback, och inbjuder till ett naturligt tänkande i iterationer.
Öppna dörrarna till projektet
Dagliga avstämningsmöten kan vara en god idé i många projekt, och ännu bättre om beställaren är inbjuden till att lyssna av dessa! Om inte det är praktiskt möjligt, kan mail eller information på intranätet vara andra praktiska lösningar – ju mer information ett projekt tillhandahåller, ju enklare är det för beställaren att förstå problem eller beslut. Tillåt inte beställaren att bli en oönskad gäst – klargör att samarbetet är en nödvändighet, men se också till att projektet är tydligt med kostnaderna för kravändring.
Ta ansvar för kraven
Ett sätt att bemöta uppfattningen att allt måste vara specificerat i detalj före projektstart är att tidigt bli en del i kravarbetet. Låt beställaren förstå att en del av projektarbetet är att arbeta fram kravbilden tillsammans med honom/henne, och att detaljera dem under projektets gång.
Jag brukar låta mina projektmedlemmar ta fullt ansvar för de krav de åtar sig att arbeta med under iterationen, och i detta ansvar ingår att uppdatera dem tillsammans med beställaren. Detta är en bra medicin mot missuppfattningar och feltolkningar som visar sig sent (och minnet av projekt där jag suttit sena kvällar och försökt förgäves hålla kraven uppdaterade med verkligheten förbleknar snabbt).
Tillåt bara en beställare
Många projekt har fallerat på grund av att mängden intressenter med lika stort mandat varit fler än en person. Endast en person har rätt att beställa förändringar i ditt projekt. Självklart kan – och bör – beställaren i många fall ta hjälp av en referensgrupp, men om du hamnar i situationen att flera personer börjar ändra kursen på ditt projekt, kanske genom att gå direkt på olika projektmedlemmar, då är katastrofen inte långt borta.
All makt till beställaren
Å andra sidan är det också viktigt att göra klart för alla att beställaren faktiskt är den som bestämmer. Om han eller hon vill leverera projektet i förtid är det ditt, eller möjligen QA-ansvariges, ansvar att tala om riskerna, men beställaren kan ta beslutet – precis som beställaren också kan bestämma sig för att lägga ned ditt projekt. Med denna makt följer också ansvaret att besluta, och som projektledare bör du hela tiden arbeta med scenarion för kommande iterationer för att underlätta beslut. Försök inte själv ta beslut som du tror beställaren skulle vilja ha det – det är ofta i längden bättre att dubbelkolla än att gissa.
Var ärlig
Försök inte smussla med problem, eller lösa buggar i smyg natten innan den stora leveransen. Alla tjänar på att informeras rakt och ärligt om läget, och ju tidigare beställaren vet om att ditt projekt ser risker med liggande tidplan, desto större är möjligheterna att göra något åt det. Fasta och omedgörliga datum visar sig ibland bero på att beställaren upplevt att de aldrig fått feedback på sina förslag, och att det då upplevts som säkrast att bestämma något och “hålla fast vid det”.
Det är tyvärr ännu idag, 2004, inte ovanligt att beställaren sålt in ett leveransdatum tillsammans med projektbeställningen, och i det läget har jag inget annat att rekommendera än att ändå stå på sig och visa de scenarios projektet kommit fram till – ofta att leveranstiden eller innehållsmängden måste justeras. Om inte beställaren kan acceptera utlåtandet från de som faktiskt ska utföra själva arbetet, ja då har du en företagsorganisation som inte kommer att tåla konkurrens från mer samspelta företag. Ditt jobb som projektledare är att konstant visa sanningen om projektet – inte att skönmåla eller nedvärdera den.
Tala samma språk
I många organisationer kommer inte beställaren från samma värld och bakgrund som projektet, och i en del fall kan mjukvaruavdelningen vara en främmande (och skrämmande) fågel i organisationen, med ett eget språk och egen projektmetodik. Detta ställer extra höga krav på dig och ditt projekt att hitta medel för att visa såväl landvinningar som problemställningar för din beställare så att han eller hon känner sig delaktig i arbetet! I ett tidigare projekt inom biotechvärlden använde jag mig framgångsrikt av termer som “försöksserier” och “hypotesprövning” för att beskriva iterativ utveckling, med god framgång. Låt oss en gång för alla begrava förtjusningen över svårbegriplig mjukvaruterminologi i det förra århundradet!