Ansvar i projekt - diskussionen går vidare

Bland det svåraste som finns i projekt är att bena ut vem som har ansvar för vad när det kommer till att se till att ett projekt levereras i tid, upplevs som lyckat och helst också kommer in på eller under budget. Den diskussion som nu har initierats av Per Vikström http://pervikstrom.wordpress.com/2010/03/25/leverantor-vs-bestallare-i-webbprojekt-vem-ska-leda-och-vems-ar-ansvaret/ och Erik Fors Andree http://definitionofdone.blogspot.com/ är viktig då den försöker sätta fingret på något som många tycker är luddigt, vad innebär det att vara projektbeställare och vilket ansvar har man kontra projektledaren eller den leverantör som man har anlitat.
Svaret är nog olika beroende på hur projektmogen organisationen är och med det menar jag hur van är verksamheten att jobba i projekt och hur erfaren är projektledaren i det som ska levereras. En oerfaren projektbeställare kan mycket väl vägas upp av en erfaren projektledare och duktiga leverantörer, allt handlar om kommunikation och dialog kring nytta eller det värde som skall skapas av projektet och tolkningen av hur detta ska gå till. Eriks modell är den jag är mest van att arbeta med och i de flesta fall fungerar den fint om man bara är medveten om dess begränsningar.
• Projektbeställare (med stöd av styrgrupp)
• Intern projektledare (beställare av konsulttjänster)
• Kundansvarig hos konsultföretag (ofta konsultföretagets projektledare)
Allt det här väcker ju naturligtvis funderingar och därför har jag försökt fylla på Pers ansvarsuppdelning som följer med mina reflektioner och erfarenheter av detta samt lagt till några punkter om projektledarens ansvar allt sett utifrån verksamhetens perspektiv eftersom det är där jag kommer från. Fortsätt gärna diskussionen med kommentarer och åsikter.

Beställarens ansvar
• Vara tydlig med sina önskemål
Det är bättre och enklare om beställaren är tydlig med vilken nytta som projektet ska leverera – det öppnar för att leverera mer än önskemålen eller att beställaren från början får klart för sig vad som går att leverera inom de ramar som satts upp iform av tid och pengar.
• Vara öppen med krav vs. ”nice to have”
Ibland vet inte beställaren vilka krav de har och om de är ”need to have” eller ”nice to have” här behövs en öppenhet att föra den typen av dialog om det är nödvändigt.
• Vara påläst kring det system som köps in
Det tror jag är ett orealistiskt krav – med tanke på att projektbeställare idag är fokuserade på nyttan av vad som ska levereras – om det görs med hjälp av Microsoft kompatibla system, Oracle eller annan teknik är ointressant ur ett beställarperspektiv. Det finns naturligtvis andra aspekter på detta såsom vilken IT plattform företaget använder och om det finns integrationsmöjligheter men det är en del av den IT policy som bör finnas i en IT intensiv organisation (tycker jag!).
• Vara tydlig med tidsram och budget
Ja men också vara öppen för förändringar i dessa om nödvändigt.
• Inte komma med ändringar efter tagna beslut – försenar projektet och påverkar tidsplan och kostnad
Beställaren har alltid rätt att komma med ändringar – men det är projektledarens ansvar att tala om konsekvenserna gentemot beställare och att kontinuerligt föra en dialog med leverantören för att förutse och underlätta ändringar.
• Bistå i utvecklingsarbetet – finnas tillgänglig för frågor
Finnas tillgänglig för frågor – är en självklarhet tycker jag –dock tror jag att det är få projektbeställaren som idag kan bistå i utvecklingsarbetet.
• Testa och godkänna den webbplats som levereras
Här måste vi skilja på olika typer av test – ofta är det ju inte projektbeställaren som är slutanvändaren – utan det är verksamheten eller allmänheten som ofta väldigt mycket fortare och lättare hittar problemen och utvecklingsmöjligheterna – här vill jag påstå att det är projektledarens ansvar att involvera dessa och sätta en toleransnivå som indikerar när projektet kan anses avslutat och utifrån det rekommendera projektbeställaren att gå över i förvaltning.

På motsvarande sätt har jag tittat på vad Per tycker är leverantörens ansvar och lagt till mina funderingar och erfarenheter på området

Leverantörens ansvarsområden
• Här vill jag börja med att lägga till det som jag tycker är viktigast:
Vara beredd att avsätta en eller ett par dagar för att introduktion till projektet med alla sina resurser. I alla mina större projekt har jag och leverantörens projektledare alltid haft en introduktion till projektet för alla resurser på båda sidor, antingen alla på en gång eller i mindre grupper och vid flera tillfällen. Om inte alla i projektet förstår vad som ska levereras – så kan de inte heller modifiera sitt hur det ska levereras. Det här är inte så vanligt har jag förstått men det har alltid upplevs som övervägande positivt och flera resurser har ofta vid projektslut kommit och tackat för att de fick en introduktion som fokuserar på den nytta som projektet är tänkt att leverera – allt annat är ju hygienfaktorer för att projektarbetet skall kunna flyta på (tidplan, budget, verktyg).
• Lyssna på beställaren
Är en självklarhet
• Konkretisera beställarens önskemål och ta fram tids- och kostnadsuppskattning (offert)
Involverar tolkning av projektets nytta och en öppenhet inför att dela med sig av den kompetens som den egna organisationen har men också att vara ödmjuk med det man inte kan leverera.
• Stödja beställaren i dennes arbete med att sätta sig in i det system som beställs, förklara funktionalitet osv
Lägg hellre krut på att se till att slutanvändarutbildning och dokumentation för dessa är tydlig och klar och att återigen stämma av att man har förstått vilken nytta projektet ska leverera. Ofta är det först när ett system har använts en tid som man verkligen förstår dess funktionalitet och också kan se begränsningar och möjligheter.
• Ta fram en tydlig dokumentation som beskriver vad som ska utvecklas – funktionsspecifikation•
För vem då? Vem läser denna ? Är det viktigt att lägga ner tid på något som ändå är inaktuellt vid projektets slut? Jag säger inte att det inte ska göras alls men kanske ska den fokusera på att beskriva nyttan av vad som ska levereras.
• Hålla kunden informerad om projektstatus och eventuella risker och förseningar
Nyckeln här är att ha en dialog – inte att informera – ett av mina sämsta projekt någonsin involverade en leverantör som bara körde avvikelserapportering mot en projektplan som för länge sen var inaktuell.
• Testa webbplatsen för att säkerställa att det som utvecklats är det som kunden beställt
Stäm av med beställaren och projektledaren om vi som leverantör levererat den nytta som projektet vill åstadkomma?
• Korrigera fel, brister, missar
Är väl en självklarhet anser jag
• Leverera en väl fungerande webbplats

Tills slut kommer några punkter om projektledarens ansvar

• Ta bara på dig att leda projekt där du känner att du förstår och själv kan se vilken nytta projektet skall leverera till verksamheten – annars kommer du att få svårt med motivationen och kommunikationen i projektet.
• Lägg ner tid på att förstå vad beställaren (verksamheten) vill uppnå och vad leverantören kan leverera
• När du ska handla upp en leverantör – välj utifrån kompetens - social såväl som teknisk! Går det inte att ha en dialog med leverantören spelar det ingen roll hur tekniskt skickliga de är – ni kommer att ha svårare att komma imål.
• När projektet är igång – ha en kontinuerlig dialog med alla resurser och med projektbeställaren för att säkerställa att alla vet hur det går och vad som händer
• Var inte rädd för att ha diskussioner kring den nytta som beställaren vill ha och som projektet skall leverera eller för den delen komma med förbättringsförslag eller att fatta obekväma beslut.
• Din roll är att tolka, kommunicera, facilitera, motivera och fatta beslut utifrån de olika situationer du hamnar i och att se till att du tillsammans med leverantören/konsulten levererar den nytta som verksamheten har behov av i ditt specifika projekt.