Konsulter · Projektledning · Webbutveckling

Leverantör vs beställare i webbprojekt – vem ska leda och vems är ansvaret?

Det kan låta som en rätt självklar fråga. Klart beställaren ska leda och styra arbetet. Eller? Kanske bör proffset – leverantören (konsulten) – leda istället?

Jag har sprungit på ovana beställare ett antal gånger under min karriär. Både när jag själv suttit på beställarsidan och haft kollegor som varit ovana beställare av webbplatser och som konsult. För att ett projekt ska lyckas tror jag att det krävs ett gemensamt ansvar.

Beställarens ansvarsområden

  • Vara tydlig med sina önskemål
  • Vara öppen med krav vs. ”nice to have”
  • Vara påläst kring det system som köps in
  • Vara tydlig med tidsram och budget
  • Inte komma med ändringar efter tagna beslut – försenar projektet och påverkar tidsplan och kostnad
  • Bistå i utvecklingsarbetet – finnas tillgänglig för frågor
  • Testa och godkänna den webbplats som levereras

Leverantörens ansvarsområden

  • Lyssna på beställaren
  • Konkretisera beställarens önskemål och ta fram tids- och kostnadsuppskattning (offert)
  • Stödja beställaren i dennes arbete med att sätta sig in i det system som beställs, förklara funktionalitet osv
  • Ta fram en tydlig dokumentation som beskriver vad som ska utvecklas – funktionsspecifikation
  • Hålla kunden informerad om projektstatus och eventuella risker och förseningar
  • Testa webbplatsen för att säkerställa att det som utvecklats är det som kunden beställt
  • Korrigera fel, brister, missar
  • Leverera en väl fungerande webbplats

Jag har säkert glömt vissa saker i listningen ovan. Mitt syfte är inte att vara komplett på något sätt, utan visa att det varken är mitt ansvar som konsult eller ditt ansvar som beställare att ett webbprojekt blir lyckat. Vi måste tillsammans ansvara för att det slutgiltiga resultatet blir korrekt och att utvecklingsprocessen går framåt. Både leverantör och beställare måste ha en viss ödmjukhet och lyssna på motparten, samtidigt som det är viktigt att vara tydlig och rak med det som gäller. God kommunikation är nyckeln till succé i mina ögon.

Och hur var det med det där att leda? Jo, jag som projektledare på konsultföretaget leder mitt utvecklingsteam och beställarens projektledare leder kundens interna arbete. Vi jobbar parallellt och stämmer av kontinuerligt för att fånga upp alla lösa frågor och hålla koll på tidsplan och budget. Låter enkelt här, men ofta är det lite mer komplicerat i verkligheten…

Håller du med mig i mitt resonemang eller har du andra funderingar? Hör gärna av dig!

20 thoughts on “Leverantör vs beställare i webbprojekt – vem ska leda och vems är ansvaret?

    1. Tack! Det fungerar sådär. Jag har mött extremer åt båda hållen. Där jag är nu har vi en ödmjuk inställning. Till största del tror jag att det beror på att det är ett litet företag som vuxit fram. Som liten måste man ha en mer ödmjuk approach för att lyckas. Det går inte att vara kaxig och köra över kunderna….

      Gilla

  1. Jag håller med om att det finns gott om beställare därute som är ovana, och det finns lika gott om beställare som ÄR vana, instatta i både domän och teknik, vana att sätta upp budgetar och tidsplaner mm och ÄNDÅ blir det fel.

    De lättrörliga principerna som jag har mycket god erfarenhet av, även om det är stökigt i början, handlar om att acceptera redan från början att förändring av beställning kommer att och måste få ske. Det är ett oundvikligt fakta inom all form av utveckling till skillnad från massproduktion som är mer förutsägbar.

    Alla som arbetar med system- eller verksamhetsutveckling vet att det inte går att veta exakt vad vi vill ha när vi beställer det. ”Det enda jag vet är att jag ingenting vet” är vad jag önskar höra från en mogen beställare – och leverantör..

    Som konsult och projektledare är det väldigt lätt att försöka göra beställaren nöjd genom att svara med en illusion av exakta estimat, och att utlova lösningar enligt en exakt spec – allt som inte står i specen ska inte få göras. Och hur ska det kunna bli ett lyckat genomförande om inte beställaren får ändra sig under tiden? Så min punktlista skulle se ut ungefär så här:

    Beställare + leverantör:
    – Skriv avtal som hanterar förändringar i krav och plan, t.om förändringar i mål och de effekter beställaren vill uppnå.

    – Arbeta upp ett förtroende genom att regelbundet visa upp levererbar programvara så att beställaren har möjlighet att ändra sig medan tid och pengar finns.

    – Kom överens med beställare om det är budgeten eller antal funktioner som är viktigt. Är det budgeten – scopa och stäm av regelbundet om beställaren får det han förväntar sig genom att visa upp resultatet löpande, så beställaren har en chans att avbryta projektet ifall det möjliga scopet visar sig för torftigt.
    Ärligt och tryggt för alla.

    – En kundrepresentant ska finnas med i utvecklingsteamet på daglig basis, helst samlokaliserad. En ratio på 2 kundrepresentanter på 3 utvecklare är det ideala – även om vi har en lång väg att gå på de flesta organisationer för att nå dit.

    – Lita på leverantören du tar in, om du inte gör det som beställare, ta inte in leverantören. Eller föreslå en kortare tidplan med mycket litet scope som kan ge leverantören en chans att visa sin förmåga avseende kvalitet och produktivitet. Avbryt samarbetet om det inte fungerar, men ge det tid att komma i ordning. Räkna inte med en perfekt leverans efter de första 3 veckorna gått.

    osv. Listan kan göras lång. Allt handlar om kontinuerligt samarbete, regelbunden kommunikation och demonstration samt ömsesidig respekt för individen. Just respekten mellan beställare och leverantör verkar vara den svåraste punkten att få till, särskilt när vi behandlar varandra som motparter istället för medparter. 🙂

    Gilla

    1. Tack för väldigt värdefulla tips och kloka tankar. Det enda som är helt säkert med ett projekt är att det inte finns något som är helt säkert. Både budget, tekniska förutsättningar och bemanning kan komma att ändras om det är ett längre projekt.

      Tror på det där du skriver om avtal och överenskommelser. Att sätta på pränt och enas kring en slags bas och sen vara överens om vad som händer vid ändringar och tillägg, som ju alltid kommer. Det blir en extra säkerhet för alla parter om man redan på förhand garderat för detta.

      Ska nog ta upp dina punkter med kollegorna imorrn… Tack än en gång!

      Gilla

  2. Ulrika :
    Jag håller med om att det finns gott om beställare därute som är ovana, och det finns lika gott om beställare som ÄR vana, instatta i både domän och teknik, vana att sätta upp budgetar och tidsplaner mm och ÄNDÅ blir det fel.

    De beställare som är vana kommer ofta antingen från en rätt tung tekniksida, eller från verksamheten där man saknar förståelse för systemutveckling. Än så länge finns få beställare som rör sig obehindrat i gränslandet mellan teknik, design och verksamhet. Och det finns väldigt få som har en design-bakgrund, vilket jag i tror i många fall vore bättre än teknik/verksamhet.

    Gilla

    1. Ett tillägg till Eriks kommentar:
      Att som beställare ha en teknisk bakgrund kan ibland nästan bli en nackdel eftersom individen då fokuserar på just teknik och inte affärsnytta, användbarhet, design osv.

      En påläst beställare med ett marknadstänk är det som jag uppskattar mest. Någon som t ex känner till hur ett content management system fungerar, men som inte funderar på .Net eller PHP. En person som vet hur stor budgeten och vilka målen som ska uppnås affärsmässigt. Då är det lättare att diskutera utan att fastna i tekniska fallgropar. Är min uppfattning.

      Återkommer med en del två i diskussionen i veckan…

      Gilla

  3. Jag tror att det också handlar om de grundläggande styrmekanismerna. Man tillmäpar helt enkelt belöningssystem som får fel effekt. Utvecklaren får beröm för tekniskt snygga lösningar, designern för cool design och redaktören för en välskriven text (ofta lång och korrekt med inte så intresseväckade). Istället borde beröm alltid vara kopplat till att man gjort en lösning där de olika perspektiven möts.

    Får man en dragning av teamet och teknikerna berättar hur tekniskt avancerad lösningen är eller designern svävar ut i vilken framtidslösning de utformat, så kan man ofta märka att den andra parten inte riktigt förstår poängen. Jag skrev lite om det tidigare http://definitionofdone.blogspot.com/2009/10/belona-kompromisser-fa-battre.html

    Gilla

  4. Jag håller helt med Erik i hans kommentarer. Grundläggande styrmekanismer och belöningssystem påverkar effekten. Kan lägga till att ”utvecklaren får beröm för tekniskt snygga lösningar, designern för cool design…” att projektledaren får beröm för omfattande dokumentation, oavsett hur läsbar, verksamhetsnyttig eller förvaltningsbar den är. Att få team att gå till högproduktivitet och stark teamkänsla på kort tid, att få in verksamhetens engagemang och besök i teamet, att synliggöra effekter och ifrågasätta lösningar mm, belönas inte lika ofta är min erfarenhet.

    Vad vill egentligen beställarna med sina investeringar? Kanske kan vi hjälpas åt att ta oss dit?

    Gilla

    1. Där kom vi till kärnan: ”Vad vill egentligen beställarna med sina investeringar?”.

      Om beställarna har en klar plan och en väl uttänkt mål är det dels lättare för leverantören (konsulten) att ta fram och leverera rätt sak. Dessutom är det lättare för beställaren att kontrollera att det är rätt sak som levereras. ”Blått klädesplagg” är inte samma sak som en ”marinblå tröja”….

      Gilla

  5. Precis. Och generellt sett vet man inte vad man vill ha 😉 Jag får ofta höra att ”vi vet ju exakt vad vi vill ha, då kan det inte vara så svårt/dyrt”. Får lust att svara ”du har inte en aning om vad du vill ha”, men man måste förstås välja lite mer diplomatiska uttryckssätt.

    Gilla

Kommentera gärna, tack!

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s